From nobody Tue Dec 1 07:40:33 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17491A9173 for ; Tue, 1 Dec 2015 07:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 0ZpjNVQzjfbf for ; Tue, 1 Dec 2015 07:40:28 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95CE1A00F9 for ; Tue, 1 Dec 2015 07:40:27 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:35642 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1a3n2W-0042NP-LW; Tue, 01 Dec 2015 10:40:27 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_C6059FD6-0C06-46DE-872C-6C197FCCDC42" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dave Rice In-Reply-To: <5606B89B-FCF0-4C75-BAB8-FB1E212F8D82@dericed.com> Date: Tue, 1 Dec 2015 10:40:22 -0500 Message-Id: <5EDBE9D2-3E2F-4865-ACF9-497706E0CA07@dericed.com> References: <21E28D45-E45F-4CBE-AC3D-6E41DCE172B9@dericed.com> <20150828065002.GH3813@bunkus.org> <5606B89B-FCF0-4C75-BAB8-FB1E212F8D82@dericed.com> To: Discussion about the current and future development of Matroska X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] [Matroska-devel] EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 15:40:32 -0000 --Apple-Mail=_C6059FD6-0C06-46DE-872C-6C197FCCDC42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On Nov 9, 2015, at 1:19 PM, Dave Rice wrote: >=20 > Hi all, >=20 >> On Oct 3, 2015, at 9:46 AM, Steve Lhomme > wrote: >> On Aug 28, 2015 17:00, "Dave Rice" > wrote: >> > >> > Hi, >> > >> >> On Aug 28, 2015, at 2:50 AM, Moritz Bunkus > wrote: >> >> >> >> Hey, >> >> >> >> I have no objections, however I don't know a lot about XML schemas = in >> >> the first place (neither about DTDs, to be honest). >> > >> > >> > Honestly, I know a lot more about XML Schemas than I do about DTDs. = As wikipedia mentions at = https://en.wikipedia.org/wiki/Document_type_definition = , DTDs have = largely been superseded by XML Schemas. And at this point I think that = XML Schemas may be a more familiar analogy to use. >> > >> > I think XML Schemas also share more in common with specdata.xml = than DTDs do. Schemas use the node and have maxOccurs and = minOccurs attributes (specdata has semantically the same thing with = mandatory and multiple), they both have a similar declaration of element = type, element name and element description. Actually I think a = semantically equivalent version of specdata.xml could be written as an = XML Schema. >> > >> > XML Schemas also offer a few advantages for machine readable = expressions; for instance XML Schemas can mandate a particular pattern = or regex for a value.=20 >> > >> >>> I propose the specdata.xml file here >> >>> = https://github.com/Matroska-Org/foundation-source/blob/master/spectool/spe= cdata.xml = >> >>> = > >> >>> is a good basis for the consideration of an EBML Schema. =46rom = what I >> >>> can see, specdata.xml is an expression of the EBML + Matroska >> >>> specifications to support automated creation of documentation, = but the >> >>> structure of this already shares a lot of similarity to XML = Schemas. >> >> >> >> >> >> For both documentation (e.g. the table on the matroska.org = specs page is >> >> generated from this file) and code (libMatroska's class hierarchy = is >> >> generated automatically from this file) actually. >> > >> > >> > Does specdata.xml play a role in mkvalidate? I'm thinking of the = potential to have an ebmlvalidator where you can provide the EBML Schema = to validate particular EBML docType. >>=20 >> Well the parsing code is generated from the XML file, so in a way, = yes. But it's not parsed "live". >>=20 >> >>> Is there a preference in handling the standardization of = Matroska: >> >>> documenting it in a similar fashion to our work in the EBML spec = or to >> >>> define what an EBML Schema is and consider matroska an expression = of >> >>> it? >> >> >> >> >> >> I'm not sure whether or not I understand the implications. But my = gut >> >> feeling is that having a definition for an EBML Schema would = benefit >> >> other formats than Matroska, too, therefore the latter seems the = way to >> >> go. >> > >> > >> > I have the same feeling: >> > - document EBML as a specification that includes rules for defining = a docType in the form of an EBML Schema >> > - write an EBML Schema (updated specdata.xml) for Matroska and = maybe webM >> > >> >>> Are some changes to specdata.xml acceptable? Such as a filename = change >> >>> or changing the name of the element of some attributes? >> >> >> >> >> >> Well, like I said above the specdata.xml is used for generating = both >> >> documentation and code. Both should stay viable. If changes to it = are >> >> made then the accompanying tools must be updated as well. >> >> >> >>> Neither the current EBML specs nor the specdata.xml specifically = refer >> >>> to the hierarchical arrangement of the elements, but this could = be >> >>> presumed by their ordering. For instance, could any level 3 = element be >> >>> a child of any level 2 Master-element? I presume not, but I don't >> >>> think it's clear anywhere what parent-child relationships are >> >>> feasible. Possibly specdata.xml and/or the EBML Schema Definition >> >>> could define the relationship between levels of related elements >> >>> similar to how an XML Schema (XSD) does. >> >> >> >> >> >> So far it is understood that an element not marked as a global = element >> >> must only occur as a child of its parent. Its parent is the last = element >> >> located before the child element in the specdata file with a lower = level >> >> than the child element. Or something like that. >> > >> > >> > This will need some documentation. That's how I've understood the = mkv spec as well but the definition for how an EBML Schema works should = be explicit about this. >>=20 > Any more opinion about how to go about (or if to go about) modifying = specdata.xml towards becoming an expression of a to-be-defined EBML = Schema for matroska and webm? As a summary of proposed changes to = specdata.xml >=20 > - change to XML Schema conventions where relevant: > - use maxOccurs attribute instead of the current = Multiple attribute. > - use minOccurs attribute instead of the current = Mandatory attribute. > - move documentation of elements to a sub-element = (allows for possible internationalization in the schema and better = semantics) > - arrange elements in hierarchical form to indicate parent-child = relationships (rather than the current practices where all elements are = defined at the same level, and you have to parse back in elements to the = one with the lower-numbered level attribute to find the parent) >=20 > A draft of specdata.xml with these changes is at = https://gist.github.com/dericed/f0a4bb0e7dc635ed1347 = . I can continue = to work on this and send back changes for advice/approval but if I do so = is there someone who could later update the tools that use specdata.xml = so that newly-defined EBML Schemas may later to be into use? I=E2=80=99m preparing a pull request on specdata.xml but want to update = the utilities in spectool at the same time so that spec2data, data2lib, = and data2spec still function properly. I=E2=80=99m having trouble = getting the spectool utilities to build properly so that I can test = them. I was able to build coremake but not sure where to go from here. = I=E2=80=99ve read spec2data and have an idea of how it works and am = thinking that I could reproduce the spec2data workflow with xsl and then = we could have a make file which uses xsltproc to convert an EBML Schema = into the Drupal table and library files as needed. Any advice on which = route to take: continue trying with getting spectool utilities to build = or redo the utilities in xsl? Best Regards, Dave Rice > btw I'm cc'ing the newly-established CELLAR listserv which focuses on = work on the EBML and Matroska specification. If you are interested in = these topics please considering subscribing at = https://www.ietf.org/mailman/listinfo/cellar = . >=20 > Best Regards, > Dave Rice >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_C6059FD6-0C06-46DE-872C-6C197FCCDC42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On Nov 9, 2015, at 1:19 PM, = Dave Rice <dave@dericed.com> wrote:

Hi all,

On Oct 3, 2015, at 9:46 AM, Steve Lhomme = <slhomme@matroska.org> wrote:

On Aug 28, 2015 17:00, "Dave Rice" <dave@dericed.com> wrote:
>
> Hi,
>
>> On Aug 28, 2015, at 2:50 AM, Moritz Bunkus <moritz@bunkus.org> = wrote:
>>
>> Hey,
>>
>> I have no objections, however I don't know a lot about XML = schemas in
>> the first place (neither about DTDs, to be honest).
>
>
> Honestly, I know a lot more about XML Schemas than I do about DTDs. = As wikipedia mentions at https://en.wikipedia.org/wiki/Document_type_definition, = DTDs have largely been superseded by XML Schemas. And at this point I = think that XML Schemas may be a more familiar analogy to use.
>
> I think XML Schemas also share more in common with specdata.xml = than DTDs do. Schemas use the <element> node and have maxOccurs = and minOccurs attributes (specdata has semantically the same thing with = mandatory and multiple), they both have a similar declaration of element = type, element name and element description. Actually I think a = semantically equivalent version of specdata.xml could be written as an = XML Schema.
>
> XML Schemas also offer a few advantages for machine readable = expressions; for instance XML Schemas can mandate a particular pattern = or regex for a value. 
>
>>> I propose the specdata.xml file here
>>> https://github.com/Matroska-Org/foundation-source/blob/master/s= pectool/specdata.xml
>>> <https://github.com/Matroska-Org/foundation-source/blob/master/s= pectool/specdata.xml>
>>> is a good basis for the consideration of an EBML Schema. = =46rom what I
>>> can see, specdata.xml is an expression of the EBML + = Matroska
>>> specifications to support automated creation of = documentation, but the
>>> structure of this already shares a lot of similarity to XML = Schemas.
>>
>>
>> For both documentation (e.g. the table on the matroska.org specs page = is
>> generated from this file) and code (libMatroska's class = hierarchy is
>> generated automatically from this file) actually.
>
>
> Does specdata.xml play a role in mkvalidate? I'm thinking of the = potential to have an ebmlvalidator where you can provide the EBML Schema = to validate particular EBML docType.

Well = the parsing code is generated from the XML file, so in a way, yes. But = it's not parsed "live".

>>> Is = there a preference in handling the standardization of Matroska:
>>> documenting it in a similar fashion to our work in the EBML = spec or to
>>> define what an EBML Schema is and consider matroska an = expression of
>>> it?
>>
>>
>> I'm not sure whether or not I understand the implications. But = my gut
>> feeling is that having a definition for an EBML Schema would = benefit
>> other formats than Matroska, too, therefore the latter seems = the way to
>> go.
>
>
> I have the same feeling:
> - document EBML as a specification that includes rules for defining = a docType in the form of an EBML Schema
> - write an EBML Schema (updated specdata.xml) for Matroska and = maybe webM
>
>>> Are some changes to specdata.xml acceptable? Such as a = filename change
>>> or changing the name of the <table> element of some = attributes?
>>
>>
>> Well, like I said above the specdata.xml is used for generating = both
>> documentation and code. Both should stay viable. If changes to = it are
>> made then the accompanying tools must be updated as well.
>>
>>> Neither the current EBML specs nor the specdata.xml = specifically refer
>>> to the hierarchical arrangement of the elements, but this = could be
>>> presumed by their ordering. For instance, could any level 3 = element be
>>> a child of any level 2 Master-element? I presume not, but I = don't
>>> think it's clear anywhere what parent-child relationships = are
>>> feasible. Possibly specdata.xml and/or the EBML Schema = Definition
>>> could define the relationship between levels of related = elements
>>> similar to how an XML Schema (XSD) does.
>>
>>
>> So far it is understood that an element not marked as a global = element
>> must only occur as a child of its parent. Its parent is the = last element
>> located before the child element in the specdata file with a = lower level
>> than the child element. Or something like that.
>
>
> This will need some documentation. That's how I've understood the = mkv spec as well but the definition for how an EBML Schema works should = be explicit about this.

Any more = opinion about how to go about (or if to go about) modifying specdata.xml = towards becoming an expression of a to-be-defined EBML Schema for = matroska and webm? As a summary of proposed changes to = specdata.xml

- = change to XML Schema conventions where relevant:
= - use maxOccurs attribute instead of the current Multiple = attribute.
- use minOccurs attribute = instead of the current Mandatory attribute.
= - move documentation of elements to a sub-element (allows for = possible internationalization in the schema and better = semantics)
- arrange elements in hierarchical = form to indicate parent-child relationships (rather than the current = practices where all elements are defined at the same level, and you have = to parse back in elements to the one with the lower-numbered level = attribute to find the parent)

A draft of specdata.xml with these = changes is at https://gist.github.com/dericed/f0a4bb0e7dc635ed1347. I = can continue to work on this and send back changes for advice/approval = but if I do so is there someone who could later update the tools that = use specdata.xml so that newly-defined EBML Schemas may later to be into = use?

I=E2=80=99m preparing a pull request on = specdata.xml but want to update the utilities in spectool at the same = time so that spec2data, data2lib, and data2spec still function properly. = I=E2=80=99m having trouble getting the spectool utilities to build = properly so that I can test them. I was able to build coremake but not = sure where to go from here. I=E2=80=99ve read spec2data and have an idea = of how it works and am thinking that I could reproduce the spec2data = workflow with xsl and then we could have a make file which uses xsltproc = to convert an EBML Schema into the Drupal table and library files as = needed. Any advice on which route to take: continue trying with getting = spectool utilities to build or redo the utilities in xsl?

Best Regards,
Dave Rice


btw I'm cc'ing the newly-established CELLAR = listserv which focuses on work on the EBML and Matroska specification. = If you are interested in these topics please considering subscribing = at https://www.ietf.org/mailman/listinfo/cellar.

Best Regards,
Dave Rice

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

= --Apple-Mail=_C6059FD6-0C06-46DE-872C-6C197FCCDC42-- From nobody Tue Dec 1 08:01:31 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485E31ACD62 for ; Tue, 1 Dec 2015 08:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.688 X-Spam-Level: X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 G8StuNituZiF for ; Tue, 1 Dec 2015 08:01:28 -0800 (PST) Received: from liselle.bunkus.org (liselle.bunkus.org [IPv6:2a01:4f8:141:318b::105:1]) (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 1B7171ACD5E for ; Tue, 1 Dec 2015 08:01:28 -0800 (PST) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 17A3FDC63D2; Tue, 1 Dec 2015 17:01:23 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 26208DC63D2; Tue, 1 Dec 2015 17:01:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2015100101; t=1448985676; bh=xNkmeE1gXtalW6ndDYulqVwCz8ICUcHFlvl4ZAhQY50=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=aqBxWamtqh7YUJXvj2Y60VITSyXhO6s2ZyRaCL27gdwhCruIdTVJWlSIovtywGSbF Icmkjz5dGhoYrHLy3zcenXEVNiYuIgpJDhml1Nt4CP3rBmArvVZ07sWkK3JoWRz7Ty sm1Q3brN2sx0p/ZpivJIS5hqU3p+uI9sn9dhNtBx9nDJwJIU4fUqcJ0UW2bv1ghJcl 9dSuaXR8jEJbRGApo+52FbK2vBS2pOcKIgrKD8SJvPaUv62IIUOEdmY8Ado06VMmAN 1jJrolqxchU5Xt3mQoNwYUdcXalSF20aV7sxqbKWoih1EqL5SPMHnqPIYjBuL5I+Rw AXANIyTBHJKlQ5rxa5S5VfcqGkIQWH/e9iXOzxlQLoKF0P7MLpGUNtpyF0wbQr5/2m tb4QI41zehJrB//CirB6TU7HHOwVe2p0vXEorRHyk/3npO6wLk0+B5BeI9tk68tNez bmo3XCPsxSBGAM05rAlaIUbxChEN1IgZq3IUwDK6+Zz6/UjY2MBSKJAYaMMAammwUI TM2UzHw2XUWsHaeHFE5r6Nl3t8cn7DtS1FUUjjp7XPmthfw79+ykRMbr80pG7UD27l kDPgpWsQTF5x8yQLO3bySDMLem0d1KmRjDRrMpfBLhdVUJFtOiTgi8g+dRAjonxUxf TMD8wK5GcZcK8nhWxGkuydRE= Received: by sweet-chili.local (Postfix, from userid 1000) id 51EA3449122; Tue, 1 Dec 2015 17:01:03 +0100 (CET) Date: Tue, 1 Dec 2015 17:01:03 +0100 From: Moritz Bunkus To: Dave Rice Message-ID: <20151201160101.GZ2936@bunkus.org> References: <21E28D45-E45F-4CBE-AC3D-6E41DCE172B9@dericed.com> <20150828065002.GH3813@bunkus.org> <5606B89B-FCF0-4C75-BAB8-FB1E212F8D82@dericed.com> <5EDBE9D2-3E2F-4865-ACF9-497706E0CA07@dericed.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cN+O50sc7gZAK+8F" Content-Disposition: inline In-Reply-To: <5EDBE9D2-3E2F-4865-ACF9-497706E0CA07@dericed.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Cc: Discussion about the current and future development of Matroska , cellar@ietf.org Subject: Re: [Cellar] [Matroska-devel] EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 16:01:30 -0000 --cN+O50sc7gZAK+8F Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, > I=E2=80=99m preparing a pull request on specdata.xml but want to update t= he > utilities in spectool at the same time so that spec2data, data2lib, > and data2spec still function properly. I=E2=80=99m having trouble getting= the > spectool utilities to build properly so that I can test them. All of that is Steve's code and I don't know a lot about coremake and the assorted build process (and there's zero documentation), but I do manage to get it to compile most of the time ;) =46rom a fresh checkout of the foundation repository[1] in ~/foundation: -------------------- 1. Build and install coremake: cd ~/foundationcorec/tools/coremake make make install Unfortunately coremake has /usr/local/share/coremake hardcoded on Linux for looking up its include files; therefore the "make install" is actually really necessary. 2. Configure the rest of the project with coremake: cd ~/foundation coremake gcc_linux_x64 3. Compile the tools (mkvtree, mkvalidator, mkclean; optional): cd ~/foundation make 4. Compile the programs in spectool: cd ~/foundation make -C spectool 5. Use the programs: # This creates spec.xml from specdata.xml. spec.xml is basically the # HTML table you see on www.matroska.org/technical/specs/: cd ~/foundation/spectools =2E./release/gcc_linux_x64/data2spec -------------------- > I was able to build coremake but not sure where to go from here. The whole foundation repo could use a serious rewrite of its build system. Steve had reasons why he created coremake, but the result is very, very complicated to use. If you (or anyone else) want to give such a rewrite a try I'd highly welcome it. > Any advice on which route to take: continue trying with getting > spectool utilities to build or redo the utilities in xsl? I'd prefer established technologies like XSLT in this case as it allows you to use a plethora of proven tools like xsltproc or any other XSLT processor (Saxon?). You can (and should) still build the tools with the instructions above so that you verify stuff works :) Kind regards, mosu [1] https://github.com/Matroska-Org/foundation-source/ --cN+O50sc7gZAK+8F Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWXcQ4AAoJEHSvAK3y4yyF9+wQANsoRoDdUyWsl+dCMXW+J4mO ncKuANuLkVvpaHryTKzBJGvkpb+LSXeW9K7TX2MdybNmwboz/zk3WzY2Q86Weztc VhpCNotitSTLafKHUAJVnGkqpt19iBCiMXjbr41hvCR+AdySANlycQDZ86IYPe4i 0bzgYD5OOykXiAR9G3hOY8SPc3CprXcw+SzHcJe2lX/rY+KRy3g7kw4F8uAULzWQ TSeGYbCUsU4Ni/HPkPtaNsIVez4VZOaCnzWompiL1/O6DkMwIfgwd+tT9fjdQbA+ AoFkkC1z9JEidtwP0vA4atS3xqmmiSgnqEuHIFHhmeShZmh/WDoI8aifgxltzXFX exwTPx1KtdIgVys42ZaYe9UstnGkZImXw1x3pkjuNNXAAwuSm/hb+263CrWLgtMk TWH3rclqex/Weq8spXhtCsL7ZUoKIKlYHSHd3TDQ1Ll1lNyHcFZs4zSn/iJZ3hhP MDZA+jb/p/rmsTS7DhhWQ4yQWNAq+COVCxLEruwB8g/Y8pHwNbuESTB3wEBXTJ/a 0a7pbbCCT3Md/WG5MzvW72fExIrLpnDkILFfinZQmuNy01SW4vinB/dNhQHpHRAb A5cb0yZBQrxfAETEx/7iV8yD7Lty2yyAiPqHts9WxTD2+jRH+efydCMLkp/G9JDO elF2cqbVWzhCrrY7h03Q =pTf7 -----END PGP SIGNATURE----- --cN+O50sc7gZAK+8F-- From nobody Wed Dec 2 11:22:55 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63951ACF5E for ; Wed, 2 Dec 2015 11:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 ygQH7PCqoRK5 for ; Wed, 2 Dec 2015 11:22:53 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107FB1ACF57 for ; Wed, 2 Dec 2015 11:22:50 -0800 (PST) Received: from [146.96.19.240] (port=29852 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1a4CzI-001zzw-P5 for cellar@ietf.org; Wed, 02 Dec 2015 14:22:50 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_6E8FB1AF-D0C4-40A1-8E8D-3F4D968A3062" Message-Id: Date: Wed, 2 Dec 2015 14:22:49 -0500 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) X-OutGoing-Spam-Status: No, score=-1.0 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-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] math in IETF specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 19:22:54 -0000 --Apple-Mail=_6E8FB1AF-D0C4-40A1-8E8D-3F4D968A3062 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear IETF lurkers, The current version of the FFV1 specification includes a lot of latex = style mathematical equations to express various aspects of the encoding = format. These can be seen in the markdown in locations like this = https://github.com/FFmpeg/FFV1/blob/master/ffv1.md#range-binary-values = = and in rendered form in HTML, = http://www.ffmpeg.org/~michael/ffv1-markdown/ffv1.html#range-coding-mode = = , and PDF, http://www.ffmpeg.org/~michael/ffv1-markdown/ffv1.pdf = . I've been investigating to see how other RFC documents integrate latex = style mathematical equations but have not found any? If there a = recommended manner to include math? Should it be translated into a = narrative? Is there a recommended way to render math in a plain text = RFC? Best Regards, Dave Rice= --Apple-Mail=_6E8FB1AF-D0C4-40A1-8E8D-3F4D968A3062 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear IETF lurkers,

The current version of the FFV1 specification includes a lot = of latex style mathematical equations to express various aspects of the = encoding format. These can be seen in the markdown in locations like = this https://github.com/FFmpeg/FFV1/blob/master/ffv1.md#range-binary= -values and in rendered form in HTML, http://www.ffmpeg.org/~michael/ffv1-markdown/ffv1.html#range-co= ding-mode, and PDF, http://www.ffmpeg.org/~michael/ffv1-markdown/ffv1.pdf.

I've been = investigating to see how other RFC documents integrate latex style = mathematical equations but have not found any? If there a recommended = manner to include math? Should it be translated into a narrative? Is = there a recommended way to render math in a plain text RFC?

Best Regards,
Dave Rice
= --Apple-Mail=_6E8FB1AF-D0C4-40A1-8E8D-3F4D968A3062-- From nobody Wed Dec 2 11:30:46 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A831ACF58 for ; Wed, 2 Dec 2015 11:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Ak4MsvTYcsct for ; Wed, 2 Dec 2015 11:30:42 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5BC1ACF16 for ; Wed, 2 Dec 2015 11:30:42 -0800 (PST) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB2JUc1A044432 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 Dec 2015 13:30:39 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Dave Rice , cellar@ietf.org References: From: Adam Roach Message-ID: <565F46D9.90801@nostrum.com> Date: Wed, 2 Dec 2015 13:30:33 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080408000501050303050006" Archived-At: Subject: Re: [Cellar] math in IETF specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 19:30:45 -0000 This is a multi-part message in MIME format. --------------080408000501050303050006 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/2/15 1:22 PM, Dave Rice wrote: > Dear IETF lurkers, > > The current version of the FFV1 specification includes a lot of latex > style mathematical equations to express various aspects of the > encoding format. These can be seen in the markdown in locations like > this > https://github.com/FFmpeg/FFV1/blob/master/ffv1.md#range-binary-values and > in rendered form in HTML, > http://www.ffmpeg.org/~michael/ffv1-markdown/ffv1.html#range-coding-mode > , > and PDF, http://www.ffmpeg.org/~michael/ffv1-markdown/ffv1.pdf > . > > I've been investigating to see how other RFC documents integrate latex > style mathematical equations but have not found any? If there a > recommended manner to include math? Should it be translated into a > narrative? Is there a recommended way to render math in a plain text RFC? > There's an effort underway to modernize the RFC format, and the new format will allow for significantly better formatting of things like mathematical formulae. See: https://tools.ietf.org/html/draft-flanagan-rfc-framework and http://www.rfc-editor.org/rse/format-faq/ It seems quite likely that this work will be reaching completion in about the same timeframe as CELLAR is ready to publish its final output. In the meanwhile, there is precedent for publishing both .txt and .pdf versions of documents, with the .txt versions referring to the .pdf for information that cannot be rendered in text. Another approach that has been taken is expression of this kind of information in algorithmic formats, using pseudocode or actual programming languages. /a --------------080408000501050303050006 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/2/15 1:22 PM, Dave Rice wrote:
Dear IETF lurkers,

The current version of the FFV1 specification includes a lot of latex style mathematical equations to express various aspects of the encoding format. These can be seen in the markdown in locations like this https://github.com/FFmpeg/FFV1/blob/master/ffv1.md#range-binary-values and in rendered form in HTML, http://www.ffmpeg.org/~michael/ffv1-markdown/ffv1.html#range-coding-mode, and PDF, http://www.ffmpeg.org/~michael/ffv1-markdown/ffv1.pdf.

I've been investigating to see how other RFC documents integrate latex style mathematical equations but have not found any? If there a recommended manner to include math? Should it be translated into a narrative? Is there a recommended way to render math in a plain text RFC?


There's an effort underway to modernize the RFC format, and the new format will allow for significantly better formatting of things like mathematical formulae. See:

https://tools.ietf.org/html/draft-flanagan-rfc-framework

and

http://www.rfc-editor.org/rse/format-faq/

It seems quite likely that this work will be reaching completion in about the same timeframe as CELLAR is ready to publish its final output.

In the meanwhile, there is precedent for publishing both .txt and .pdf versions of documents, with the .txt versions referring to the .pdf for information that cannot be rendered in text.

Another approach that has been taken is expression of this kind of information in algorithmic formats, using pseudocode or actual programming languages.

/a


--------------080408000501050303050006-- From nobody Wed Dec 2 11:52:53 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCC31B2B03 for ; Wed, 2 Dec 2015 11:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 hoOjWK9prX9c for ; Wed, 2 Dec 2015 11:52:49 -0800 (PST) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5AF21B2AC2 for ; Wed, 2 Dec 2015 11:52:49 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id F0E0BBFF60 for ; Wed, 2 Dec 2015 19:52:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woc2dLc1yCGv for ; Wed, 2 Dec 2015 19:52:48 +0000 (UTC) Received: from [10.252.28.140] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id DA49ABFC9B for ; Wed, 2 Dec 2015 19:52:48 +0000 (UTC) Message-ID: <565F4C10.9040705@xiph.org> Date: Wed, 02 Dec 2015 11:52:48 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: <565F46D9.90801@nostrum.com> In-Reply-To: <565F46D9.90801@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] math in IETF specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 19:52:52 -0000 Adam Roach wrote: > It seems quite likely that this work will be reaching completion in > about the same timeframe as CELLAR is ready to publish its final output. Given some of our milestone dates, that may be optimistic (or rather, the milestones may be optimistic). >> I've been investigating to see how other RFC documents integrate latex >> style mathematical equations but have not found any? If there a >> recommended manner to include math? Should it be translated into a >> narrative? Is there a recommended way to render math in a plain text RFC? RFC 6716 is probably one of the more involved RFCs, mathematically. You can see what we did there ( is a good example). But mostly this involves a bunch of manual work. It's not hard, but let me say I'm looking forward to the upcoming better tooling. From nobody Wed Dec 2 12:04:10 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACA31B2C67 for ; Wed, 2 Dec 2015 12:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 NN0Zx6WiUyds for ; Wed, 2 Dec 2015 12:04:07 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9551B2C5F for ; Wed, 2 Dec 2015 12:04:07 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB2K45Wu053142 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 Dec 2015 14:04:06 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "Timothy B. Terriberry" , cellar@ietf.org References: <565F46D9.90801@nostrum.com> <565F4C10.9040705@xiph.org> From: Adam Roach Message-ID: <565F4EB5.4000504@nostrum.com> Date: Wed, 2 Dec 2015 14:04:05 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <565F4C10.9040705@xiph.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] math in IETF specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 20:04:09 -0000 On 12/2/15 13:52, Timothy B. Terriberry wrote: > Adam Roach wrote: >> It seems quite likely that this work will be reaching completion in >> about the same timeframe as CELLAR is ready to publish its final output. > > Given some of our milestone dates, that may be optimistic (or rather, > the milestones may be optimistic). You're right. I had "end of 2016" in my head, but that's the *final* milestone rather than the *initial* milestone. The RFC format effort will probably come too late, in that case. /a From nobody Wed Dec 2 20:39:21 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2141B3018 for ; Wed, 2 Dec 2015 20:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 O3A1TsOkCcOq for ; Wed, 2 Dec 2015 20:39:16 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16121B3015 for ; Wed, 2 Dec 2015 20:39:16 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:37535 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1a4Lfk-003K6s-DS; Wed, 02 Dec 2015 23:39:16 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dave Rice In-Reply-To: <565F4C10.9040705@xiph.org> Date: Wed, 2 Dec 2015 23:39:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <565F46D9.90801@nostrum.com> <565F4C10.9040705@xiph.org> To: "Timothy B. Terriberry" X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] math in IETF specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 04:39:20 -0000 Hi Tim, > On Dec 2, 2015, at 2:52 PM, Timothy B. Terriberry = wrote: >=20 > Adam Roach wrote: >> It seems quite likely that this work will be reaching completion in >> about the same timeframe as CELLAR is ready to publish its final = output. >=20 > Given some of our milestone dates, that may be optimistic (or rather, = the milestones may be optimistic). >=20 >>> I've been investigating to see how other RFC documents integrate = latex >>> style mathematical equations but have not found any? If there a >>> recommended manner to include math? Should it be translated into a >>> narrative? Is there a recommended way to render math in a plain text = RFC? >=20 > RFC 6716 is probably one of the more involved RFCs, mathematically. = You can see what we did there = ( is a good = example). But mostly this involves a bunch of manual work. It's not = hard, but let me say I'm looking forward to the upcoming better tooling. Thanks, it=E2=80=99s good to see the options in action. Given what is = available in the timeline of the project it may be easiest to leave the = math in LaTeX form and cite the PDF version for reference. The ASCII Art = equations of RFC 6716 are impressive but I=E2=80=99d worry that in this = effort that it would compromise legibility. In the current FFV1 LaTeX = there are some examples with subscripts of subscripts of subscripts. Best Regards, Dave Rice= From nobody Wed Dec 2 20:48:45 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A7B1B3042 for ; Wed, 2 Dec 2015 20:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 F4qiV3x-QQZ5 for ; Wed, 2 Dec 2015 20:48:42 -0800 (PST) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB521B3040 for ; Wed, 2 Dec 2015 20:48:42 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 37A08C01FC for ; Thu, 3 Dec 2015 04:48:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-yhoFpVM3lu for ; Thu, 3 Dec 2015 04:48:42 +0000 (UTC) Received: from [172.17.0.39] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 07341C008B for ; Thu, 3 Dec 2015 04:48:42 +0000 (UTC) Message-ID: <565FC9A9.1050604@xiph.org> Date: Wed, 02 Dec 2015 20:48:41 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: <565F46D9.90801@nostrum.com> <565F4C10.9040705@xiph.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cellar] math in IETF specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 04:48:44 -0000 Dave Rice wrote: > Thanks, it’s good to see the options in action. Given what is available in the timeline of the project it may be easiest to leave the math in LaTeX form and cite the PDF version for reference. The ASCII Art equations of RFC 6716 are impressive but I’d worry that in this effort that it would compromise legibility. In the current FFV1 LaTeX there are some examples with subscripts of subscripts of subscripts. Yes, in 6716 we probably would have done that as C-style arrays (our syntax closer to C than traditional mathematical notation, on the whole). But doing that conversion for a bunch of existing equations would be a lot of work. From nobody Thu Dec 3 15:50:37 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12511ACD34 for ; Thu, 3 Dec 2015 15:50:35 -0800 (PST) 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 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 k0LAajm9-1V8 for ; Thu, 3 Dec 2015 15:50:34 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A64E1A891B for ; Thu, 3 Dec 2015 15:50:34 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:38415 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1a4ddw-000GWG-Fb; Thu, 03 Dec 2015 18:50:33 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dave Rice In-Reply-To: <20151201160101.GZ2936@bunkus.org> Date: Thu, 3 Dec 2015 18:50:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21E28D45-E45F-4CBE-AC3D-6E41DCE172B9@dericed.com> <20150828065002.GH3813@bunkus.org> <5606B89B-FCF0-4C75-BAB8-FB1E212F8D82@dericed.com> <5EDBE9D2-3E2F-4865-ACF9-497706E0CA07@dericed.com> <20151201160101.GZ2936@bunkus.org> To: Moritz Bunkus , cellar@ietf.org X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Discussion about the current and future development of Matroska Subject: Re: [Cellar] [Matroska-devel] EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 23:50:36 -0000 Thanks Moritz, > On Dec 1, 2015, at 11:01 AM, Moritz Bunkus wrote: >=20 > Hey, >=20 >> I=E2=80=99m preparing a pull request on specdata.xml but want to = update the >> utilities in spectool at the same time so that spec2data, data2lib, >> and data2spec still function properly. I=E2=80=99m having trouble = getting the >> spectool utilities to build properly so that I can test them. >=20 > All of that is Steve's code and I don't know a lot about coremake and > the assorted build process (and there's zero documentation), but I do > manage to get it to compile most of the time ;) >=20 > =46rom a fresh checkout of the foundation repository[1] in = ~/foundation: >=20 > -------------------- >=20 > 1. Build and install coremake: >=20 > cd ~/foundationcorec/tools/coremake > make > make install >=20 > Unfortunately coremake has /usr/local/share/coremake hardcoded on = Linux > for looking up its include files; therefore the "make install" is > actually really necessary. >=20 > 2. Configure the rest of the project with coremake: >=20 > cd ~/foundation > coremake gcc_linux_x64 >=20 > 3. Compile the tools (mkvtree, mkvalidator, mkclean; optional): >=20 > cd ~/foundation > make >=20 > 4. Compile the programs in spectool: >=20 > cd ~/foundation > make -C spectool >=20 > 5. Use the programs: >=20 > # This creates spec.xml from specdata.xml. spec.xml is basically the > # HTML table you see on www.matroska.org/technical/specs/: >=20 > cd ~/foundation/spectools > ../release/gcc_linux_x64/data2spec >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 These instructions worked well. To help the next person who happens = along, I converted your notes into a basic README which I sent as a pull = request here: https://github.com/Matroska-Org/foundation-source/pull/6.=20= >> I was able to build coremake but not sure where to go from here. >=20 > The whole foundation repo could use a serious rewrite of its build > system. Steve had reasons why he created coremake, but the result is > very, very complicated to use. If you (or anyone else) want to give = such > a rewrite a try I'd highly welcome it. I am interested in the foundation repo since it is the home of the = Matroska instance of the basis of the conceptual EBML Schema = (specdata.xml). To work on moving the current state of specdata.xml = towards a more standardized EBML Schema expression I should synchronize = the work on specdata.xml to the spectools so that the foundation repo = doesn=E2=80=99t break because of IETF work. The rest of the foundation repo may be out of scope to the charter. = There is obviously a lot of documentation on Matroska use on = matroska.org but that appears to be based in your Drupal site rather = than this repo. I think we still need a good method to handle linking pull requests, = comments, and discussion upon the Matroska documentation. Drupal makes = this a bit difficult. Should we move some of this documentation to = GitHub as well and have a similar process as spec.xml with the other = documentation (i.e. build it from a repo and copy/paste it to Drupal). = Or potentially we could move some Matroska documentation from Drupal to = GitHub gh-pages as done with the EBML Specification website (formerly on = sourceforge). >> Any advice on which route to take: continue trying with getting >> spectool utilities to build or redo the utilities in xsl? >=20 > I'd prefer established technologies like XSLT in this case as it = allows > you to use a plethora of proven tools like xsltproc or any other XSLT > processor (Saxon?). You can (and should) still build the tools with = the > instructions above so that you verify stuff works :) This is verified. If XSLT is welcome I certainly think it=E2=80=99s much = more familiar. Thanks, Dave Rice > Kind regards, > mosu >=20 > [1] https://github.com/Matroska-Org/foundation-source/ > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Fri Dec 4 19:34:11 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE671B36D3 for ; Fri, 4 Dec 2015 19:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 UspJ3xzGrhbb for ; Fri, 4 Dec 2015 19:34:07 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 6A3F71B36CD for ; Fri, 4 Dec 2015 19:34:07 -0800 (PST) Received: by qgcc31 with SMTP id c31so105308922qgc.3 for ; Fri, 04 Dec 2015 19:34:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jzeHJTV+s0/I3O0KfI00ul7l8hEtKRFDEkrzKtE6kCY=; b=BurgZ8qRnHdDeLdm/LjfGcMRzd7KubuAflPj8OlAyj/raa1EO8uUTP2ZF0HjbJ/iwh zNZC9eekXvjDPKSq8Sz7HZWimNvE+4iuPyaMUDLn2IjgTyQmmzOuVZL5LvoczhpudUTl ZYqpwF+Wq9I+IlGBUXauvjcKs1K7gg98IPJp3KAeKJSsIz7hAaFQ6zxwsI2D81SZsz70 QIS9jcM4F0BZLhjEsMsc2TZHBBrIAjNMNbW93y0ofDamw3N1M0dTR62ntMt8Q0RlYt3f LcvQCTENNaJO+GsEjkyjYVntZvIRNaPidP099n271vVebIPCwnLrn1m0tD85IvDn003a 5EzA== MIME-Version: 1.0 X-Received: by 10.140.32.196 with SMTP id h62mr23382926qgh.16.1449286446226; Fri, 04 Dec 2015 19:34:06 -0800 (PST) Received: by 10.55.93.196 with HTTP; Fri, 4 Dec 2015 19:34:06 -0800 (PST) In-Reply-To: References: <21E28D45-E45F-4CBE-AC3D-6E41DCE172B9@dericed.com> <20150828065002.GH3813@bunkus.org> <5606B89B-FCF0-4C75-BAB8-FB1E212F8D82@dericed.com> <5EDBE9D2-3E2F-4865-ACF9-497706E0CA07@dericed.com> <20151201160101.GZ2936@bunkus.org> Date: Fri, 4 Dec 2015 22:34:06 -0500 Message-ID: From: Ashley Blewer To: Discussion about the current and future development of Matroska Content-Type: multipart/alternative; boundary=001a113a7528ce220305261e4b07 Archived-At: Cc: cellar@ietf.org, Moritz Bunkus Subject: Re: [Cellar] [Matroska-devel] EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ashley.blewer@gmail.com 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, 05 Dec 2015 03:34:10 -0000 --001a113a7528ce220305261e4b07 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I want to second encouragement for a move off of a platform that doesn't support open source collaboration (Drupal site) and into something that does (GitHub Readme and/or gh-pages). I'm also happy to volunteer the time & effort to making this happen. My best, Ashley Blewer On Thu, Dec 3, 2015 at 6:50 PM, Dave Rice wrote: > Thanks Moritz, > > On Dec 1, 2015, at 11:01 AM, Moritz Bunkus wrote: > > > > Hey, > > > >> I=E2=80=99m preparing a pull request on specdata.xml but want to updat= e the > >> utilities in spectool at the same time so that spec2data, data2lib, > >> and data2spec still function properly. I=E2=80=99m having trouble gett= ing the > >> spectool utilities to build properly so that I can test them. > > > > All of that is Steve's code and I don't know a lot about coremake and > > the assorted build process (and there's zero documentation), but I do > > manage to get it to compile most of the time ;) > > > > From a fresh checkout of the foundation repository[1] in ~/foundation: > > > > -------------------- > > > > 1. Build and install coremake: > > > > cd ~/foundationcorec/tools/coremake > > make > > make install > > > > Unfortunately coremake has /usr/local/share/coremake hardcoded on Linux > > for looking up its include files; therefore the "make install" is > > actually really necessary. > > > > 2. Configure the rest of the project with coremake: > > > > cd ~/foundation > > coremake gcc_linux_x64 > > > > 3. Compile the tools (mkvtree, mkvalidator, mkclean; optional): > > > > cd ~/foundation > > make > > > > 4. Compile the programs in spectool: > > > > cd ~/foundation > > make -C spectool > > > > 5. Use the programs: > > > > # This creates spec.xml from specdata.xml. spec.xml is basically the > > # HTML table you see on www.matroska.org/technical/specs/: > > > > cd ~/foundation/spectools > > ../release/gcc_linux_x64/data2spec > > > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94 > > These instructions worked well. To help the next person who happens along= , > I converted your notes into a basic README which I sent as a pull request > here: https://github.com/Matroska-Org/foundation-source/pull/6. > > >> I was able to build coremake but not sure where to go from here. > > > > The whole foundation repo could use a serious rewrite of its build > > system. Steve had reasons why he created coremake, but the result is > > very, very complicated to use. If you (or anyone else) want to give suc= h > > a rewrite a try I'd highly welcome it. > > I am interested in the foundation repo since it is the home of the > Matroska instance of the basis of the conceptual EBML Schema > (specdata.xml). To work on moving the current state of specdata.xml towar= ds > a more standardized EBML Schema expression I should synchronize the work = on > specdata.xml to the spectools so that the foundation repo doesn=E2=80=99t= break > because of IETF work. > > The rest of the foundation repo may be out of scope to the charter. There > is obviously a lot of documentation on Matroska use on matroska.org but > that appears to be based in your Drupal site rather than this repo. > > I think we still need a good method to handle linking pull requests, > comments, and discussion upon the Matroska documentation. Drupal makes th= is > a bit difficult. Should we move some of this documentation to GitHub as > well and have a similar process as spec.xml with the other documentation > (i.e. build it from a repo and copy/paste it to Drupal). Or potentially w= e > could move some Matroska documentation from Drupal to GitHub gh-pages as > done with the EBML Specification website (formerly on sourceforge). > > >> Any advice on which route to take: continue trying with getting > >> spectool utilities to build or redo the utilities in xsl? > > > > I'd prefer established technologies like XSLT in this case as it allows > > you to use a plethora of proven tools like xsltproc or any other XSLT > > processor (Saxon?). You can (and should) still build the tools with the > > instructions above so that you verify stuff works :) > > This is verified. If XSLT is welcome I certainly think it=E2=80=99s much = more > familiar. > Thanks, > Dave Rice > > > Kind regards, > > mosu > > > > [1] https://github.com/Matroska-Org/foundation-source/ > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel@lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > --001a113a7528ce220305261e4b07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I want to second encouragement for a move off of a platfor= m that doesn't support open source collaboration (Drupal site) and into= something that does (GitHub Readme and/or gh-pages). I'm also happy to= volunteer the time & effort to making this happen.

= My best,
Ashley Blewer

=
On Thu, Dec 3, 2015 at 6:50 PM, Dave Rice <dave@= dericed.com> wrote:
Thanks = Moritz,
> On Dec 1, 2015, at 11:01 AM, Moritz Bunkus <= moritz@bunkus.org> wrote:
>
> Hey,
>
>> I=E2=80=99m preparing a pull request on specdata.xml but want to u= pdate the
>> utilities in spectool at the same time so that spec2data, data2lib= ,
>> and data2spec still function properly. I=E2=80=99m having trouble = getting the
>> spectool utilities to build properly so that I can test them.
>
> All of that is Steve's code and I don't know a lot about corem= ake and
> the assorted build process (and there's zero documentation), but I= do
> manage to get it to compile most of the time ;)
>
> From a fresh checkout of the foundation repository[1] in ~/foundation:=
>
> --------------------
>
> 1. Build and install coremake:
>
> cd ~/foundationcorec/tools/coremake
> make
> make install
>
> Unfortunately coremake has /usr/local/share/coremake hardcoded on Linu= x
> for looking up its include files; therefore the "make install&quo= t; is
> actually really necessary.
>
> 2. Configure the rest of the project with coremake:
>
> cd ~/foundation
> coremake gcc_linux_x64
>
> 3. Compile the tools (mkvtree, mkvalidator, mkclean; optional):
>
> cd ~/foundation
> make
>
> 4. Compile the programs in spectool:
>
> cd ~/foundation
> make -C spectool
>
> 5. Use the programs:
>
> # This creates spec.xml from specdata.xml. spec.xml is basically the > # HTML table you see on www.matroska.org/technical/spec= s/:
>
> cd ~/foundation/spectools
> ../release/gcc_linux_x64/data2spec
>
> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94

These instructions worked well. To help the next person who happens along, = I converted your notes into a basic README which I sent as a pull request h= ere: https://github.com/Matroska-Org/foundat= ion-source/pull/6.

>> I was able to build coremake but not sure where to go from here. >
> The whole foundation repo could use a serious rewrite of its build
> system. Steve had reasons why he created coremake, but the result is > very, very complicated to use. If you (or anyone else) want to give su= ch
> a rewrite a try I'd highly welcome it.

I am interested in the foundation repo since it is the home of the M= atroska instance of the basis of the conceptual EBML Schema (specdata.xml).= To work on moving the current state of specdata.xml towards a more standar= dized EBML Schema expression I should synchronize the work on specdata.xml = to the spectools so that the foundation repo doesn=E2=80=99t break because = of IETF work.

The rest of the foundation repo may be out of scope to the charter. There i= s obviously a lot of documentation on Matroska use on matroska.org but that a= ppears to be based in your Drupal site rather than this repo.

I think we still need a good method to handle linking pull requests, commen= ts, and discussion upon the Matroska documentation. Drupal makes this a bit= difficult. Should we move some of this documentation to GitHub as well and= have a similar process as spec.xml with the other documentation (i.e. buil= d it from a repo and copy/paste it to Drupal). Or potentially we could move= some Matroska documentation from Drupal to GitHub gh-pages as done with th= e EBML Specification website (formerly on sourceforge).

>> Any advice on which route to take: continue trying with getting >> spectool utilities to build or redo the utilities in xsl?
>
> I'd prefer established technologies like XSLT in this case as it a= llows
> you to use a plethora of proven tools like xsltproc or any other XSLT<= br> > processor (Saxon?). You can (and should) still build the tools with th= e
> instructions above so that you verify stuff works :)

This is verified. If XSLT is welcome I certainly think it=E2=80=99s = much more familiar.
Thanks,
Dave Rice

> Kind regards,
> mosu
>
> [1] https://github.com/Matroska-Org/foundatio= n-source/
> _____________________________________= __________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
____________________________= ___________________
Matroska-devel mailing list
Matroska-devel@lists.m= atroska.org
http://lists.matroska.org/cgi-bin/m= ailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gm= ane.org/gmane.comp.multimedia.matroska.devel

--001a113a7528ce220305261e4b07-- From nobody Fri Dec 4 23:07:24 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D231A1AC7E8 for ; Fri, 4 Dec 2015 23:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 h3c1Qyj4vWyD for ; Fri, 4 Dec 2015 23:07:21 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCE21AC529 for ; Fri, 4 Dec 2015 23:07:21 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:45324 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1a56wC-0000oL-3O for cellar@ietf.org; Sat, 05 Dec 2015 02:07:21 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_4E705587-7162-43EC-833F-7957A8A47937" Message-Id: <7B3D0399-D9DF-4800-A9B5-7CC6A3180232@dericed.com> Date: Sat, 5 Dec 2015 02:07:16 -0500 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] Defining EBML Schema in the EBML spec & mandatory/default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2015 07:07:24 -0000 --Apple-Mail=_4E705587-7162-43EC-833F-7957A8A47937 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, but particularly calling out Michael Bradshaw and Steve Lhomme = for a review, I just submitted a pull request to the EBML Specification here = The intent = is to offering a description within the EBML Specification regarding to = how make a machine-readable definition of an EBML Document Type. This is = a bit analogous to saying how to make something like an XML Schema for = the Matroska or webM types of EBML Documents. The current machine-readable spec of Matroska is available here = I hope to soon propose = changes to this to align it more so with XML Schema practices (i.e. use = attributes like minOccurs/maxOccurs instead of the current = mandatory/multiple attributes as well as nesting element = hierarchically). For now I think it would be best to start with this = pull request to start a definition of how to express specifications for = EBML DocTypes and get it in alignment with that current Matroska = implementation of that. In this commit = I removed the `EBML Template` section which was = a list of attributes to use to define an EBML Element with very brief = descriptions. This is replaced by a few paragraphs to introduce the = concept of an EBML Schema and then a table of attributes to define EBML = Elements and the definitions of those attributes. The table is a little = hard to read in the pull request but there is a rendered copy of the = table here = . In another commit = I added a more detailed description of the = associated requirements of EBML Element usage that are conveyed by = various combinations of the default and mandatory element. Since this = topic has been long discussed and a source of confusion, I=E2=80=99d = like to be precise here. There seem to be three factors involved = regarding if a mandatory element should be written to a file or not (is = there a default value declared?, is the value equal to the default?, and = is the parent element used?). I eventually ended up making a lookup = table = to say if the Element = MUST be written or not. Feedback requested. Thanks much, Dave Rice= --Apple-Mail=_4E705587-7162-43EC-833F-7957A8A47937 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all, but particularly calling out Michael Bradshaw and = Steve Lhomme for a review,

I just submitted a pull request to the EBML = Specification here  The intent is to offering a description within = the EBML Specification regarding to how make a machine-readable = definition of an EBML Document Type. This is a bit analogous to saying = how to make something like an XML Schema for the Matroska or webM types = of EBML Documents.

The current machine-readable spec of Matroska is = available here  I hope to soon propose changes to this to = align it more so with XML Schema practices (i.e. use attributes like = minOccurs/maxOccurs instead of the current mandatory/multiple attributes = as well as nesting element hierarchically). For now I think it would be = best to start with this pull request to start a definition of how to = express specifications for EBML DocTypes and get it in alignment with = that current Matroska implementation of that.

In this commit  I removed the = `EBML Template` section which was a list of attributes to use to define = an EBML Element with very brief descriptions. This is replaced by a few = paragraphs to introduce the concept of an EBML Schema and then a table = of attributes to define EBML Elements and the definitions of those = attributes. The table is a little hard to read in the pull request but = there is a rendered copy of the table here.

In another commit I added a more = detailed description of the associated requirements of EBML Element = usage that are conveyed by various combinations of the default and = mandatory element. Since this topic has been long discussed and a source = of confusion, I=E2=80=99d like to be precise here. There seem to be = three factors involved regarding if a mandatory element should be = written to a file or not (is there a default value declared?, is the = value equal to the default?, and is the parent element used?). I = eventually ended up making a lookup table to say if the Element MUST be written or = not.

Feedback = requested.

Thanks much,
Dave = Rice
= --Apple-Mail=_4E705587-7162-43EC-833F-7957A8A47937-- From nobody Sat Dec 5 00:39:09 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD441A1B7B for ; Sat, 5 Dec 2015 00:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TBSf31gR5UId for ; Sat, 5 Dec 2015 00:39:06 -0800 (PST) Received: from liselle.bunkus.org (liselle.bunkus.org [176.9.1.148]) (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 A6D631A1B74 for ; Sat, 5 Dec 2015 00:39:06 -0800 (PST) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 2B9B4DC67E2; Sat, 5 Dec 2015 09:39:01 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id A10BBDC61E4; Sat, 5 Dec 2015 09:38:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2015100101; t=1449304739; bh=wu6U7ONmL5ugUgWCUNufyRhwLDRq0QMh6v39/IY5kKs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=H5Rl26cUbBXlQqgcexkJkjx8NT5KTxm4xGUrTPI7y4K+WJfdZ2zkUzafvOfXOzmGI Y5exNU0inivNwjXWqZoYYL/hkUlVPBxRuwbxqSkZyzYheOYmV3DweVew3cYR5lxfeQ 3ckl4HIFM1HTPBx/kfO0xPrYBLwIBuGdyaPkKrTbDIHxvw374GrE+BqYW3l1Wrr4js AXpv1ci3JnScAQYPAw737mJDolM1Z23+2imZWpQYpCMfBBmMoHiI688HK1qfGFj6PK VrBieQ7KI8FPT2CZOfMTi2Exx6OwVBw6RaXG34RVlet15/Nj5GA/SD9YNKSDokHFV2 U/GwYyhpYCaEkwrBaJ3aLAv3uDyUVglzcSvLn7uRX2OsElXP8H4k+EnsdgHprBqNnj dhGuoVaAgz+fX9DiA0/Fs8EbP6lfFC0STwcjDW4bkt6whX8pfLy0EGYoW/mR7VlwWk fqaUntL+Z0xZFR86HBOIhoS5XU2uCJukdC3d1ahLPCnYH25Pixb52RCO9UPTZv9Akj YZntI3VbWYsWbAlrNp+YHa/qgYi/cPXafAE/X5iZzE9+oKgdqvmTlOjhrdOUDVl2At oxaCCoM5aDSzeVa5AOg0rcf6GIYuboug+MgEp17Rf6a7+BLk4MqYkCsrZEsmPzw7Pd cQqHF44wi7WasibIJpKnEoEI= Received: by sweet-chili.local (Postfix, from userid 1000) id 38924484B1E; Sat, 5 Dec 2015 09:38:47 +0100 (CET) Date: Sat, 5 Dec 2015 09:38:47 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20151205083846.GA23795@bunkus.org> References: <21E28D45-E45F-4CBE-AC3D-6E41DCE172B9@dericed.com> <20150828065002.GH3813@bunkus.org> <5606B89B-FCF0-4C75-BAB8-FB1E212F8D82@dericed.com> <5EDBE9D2-3E2F-4865-ACF9-497706E0CA07@dericed.com> <20151201160101.GZ2936@bunkus.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Cc: matroska-devel@lists.matroska.org Subject: Re: [Cellar] [Matroska-devel] EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2015 08:39:08 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, > I want to second encouragement for a move off of a platform that doesn't > support open source collaboration (Drupal site) and into something that > does (GitHub Readme and/or gh-pages). I'm perfectly fine with this. Kind regards, mosu --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWYqKRAAoJEHSvAK3y4yyFhtcP/iEhRuY/tXT48GOCFc5B8maU T8PDgX4JhpKI7o+l1/hxrjUb0VrkOr5XgizHFyHb/CTTEFPxogvzoQcqZ0UXR2Dt /K09JXdJ47X60TMhjuJXC6HuSgYVy9qzRTRz2YyqJgfwS9mCmWPWc2ymeOv7POGf TMyeWdZv7GSv8gtuOOGqDSGOwvG62pJ73Qzn3Q+CZz71u9lM7ONe4tj2lVE5yRDK LUm/dtVeqUSkC6jbOiuKgkgVauPU6Jgt3zHLDKGDOoGQ8HdO7shiUxjfLx9HxLaD VUgcTWD2IRIcgSZL1M2iwILGhBLwXRm3jo8t4JMJ+7dox9PjheYzqGxVz1rvfyii +zvMmbGMSpheUGsZkYlStEGkd+HVvi0kE0dDe4kNZlYRoW/v2PpB2l0IoQjco8jH px3fCV/wlOuIqPyqECSM6REoQ1nsodhblrKkGperlYxdReIxxaDyzzrtLVx4AwyA 8EYIUlW/Utnl0heepFYXhbXCWn23gfXp6tZvhps0HZyl3o3w9Ov0wKNPg7d7g+At SCsLC8ow1dpzVkx7aXspiEnOmg16TVrJZ0s1gvMkbnm2Lswq7hxX4/fVoZquI8Um mN6La9YveZtSH4NfAK9LVPo5WZ8LdfqnEmmhoq4r8ge8IxJrxHlAt4ECQn6x+Zop q0ZZS6I0xWIhVd6WOmOu =9Q/n -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From nobody Sat Dec 5 09:25:22 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B301A88B9 for ; Sat, 5 Dec 2015 09:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.128 X-Spam-Level: X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 rEnMHvVsJBm8 for ; Sat, 5 Dec 2015 09:25:18 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 8BB211A88A5 for ; Sat, 5 Dec 2015 09:25:18 -0800 (PST) Received: by pfu207 with SMTP id 207so42148640pfu.2 for ; Sat, 05 Dec 2015 09:25:18 -0800 (PST) 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:content-type; bh=7XXrmsV8HdrvQCnvca8FEFk6DOMolPIylZ9zrg84bb0=; b=n+QnN27GUFPEqBvxKDM6nXb8sHn5RGp0WhMvAuXkXbwwuORWOxLPEiKVdffpXRfNxt 92M8qA7noMfKnZ0J9HBT+wqk5HxM6fxCQxTOolSBngJMWTSn7aoE8P5+PFftw6DhmVX7 /LZkuLGcP/Sr6Nvw2/JY/iBrj+yfo0UFXWbcDWqHDBIUnlbaSiE/mdRoKw/Rm1c7qJlr 2GZqoTFbyIJtKyu1xWYzpIF78Cs7CAE5RWZoSrk0gVj/tDYhmawGy0BYPijubEuPz8C5 T7MmMk0i9rwlijQusU3hQmN776dPD/3ZvLcPRoQOc1nk9nZahg+l179zEYhOQ6s/mc5r 1Png== 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-type; bh=7XXrmsV8HdrvQCnvca8FEFk6DOMolPIylZ9zrg84bb0=; b=GGtAfRp7+UnH80dLX9NF80bq2SrQ084dwfS4zM6s8f1YF1w1wARKDIXywzhJtg0K0G cLwtWkoY/3zwYqDVlxxUAqGUjtY0C5opPunC/2cLYfUrG2E3RJfPquf9sFUWXoMpNcze 7/0v1+AMAnibPN0BMgjxpGj+q6OGyyhDUrUdhriVOgU6LYkfAS7GOTTk0MEn38I0LeKj 57AjYudX7UUdxy18eoFSS4oRUunOOe6EMvRn3idU93j0VJAdt7PCvLLydFV9pd7+Slpz foQuxqRnwujqad488H5lemoriunt6hQj1qwyISe6ddSf7o+SDSuJFW4+K+TmuaKcZy1K LsqA== X-Gm-Message-State: ALoCoQk82pw73scM2wKjufAQPqncikp3tWXW1iX0ehiG43bW+uoD9ccWFGiSQEZLvoLSKD/M3ig6 X-Received: by 10.98.76.1 with SMTP id z1mr30653228pfa.115.1449336318165; Sat, 05 Dec 2015 09:25:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.156.165 with HTTP; Sat, 5 Dec 2015 09:24:58 -0800 (PST) In-Reply-To: <7B3D0399-D9DF-4800-A9B5-7CC6A3180232@dericed.com> References: <7B3D0399-D9DF-4800-A9B5-7CC6A3180232@dericed.com> From: Michael Bradshaw Date: Sat, 5 Dec 2015 09:24:58 -0800 Message-ID: To: Dave Rice Content-Type: multipart/alternative; boundary=001a11354dda67b395052629e8fd Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Defining EBML Schema in the EBML spec & mandatory/default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2015 17:25:20 -0000 --001a11354dda67b395052629e8fd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Overall I like it. I've added some questions/nits to the GitHub pull request. On Fri, Dec 4, 2015 at 11:07 PM, Dave Rice wrote: > Hi all, but particularly calling out Michael Bradshaw and Steve Lhomme fo= r > a review, > > I just submitted a pull request to the EBML Specification here > The intent > is to offering a description within the EBML Specification regarding to h= ow > make a machine-readable definition of an EBML Document Type. This is a bi= t > analogous to saying how to make something like an XML Schema for the > Matroska or webM types of EBML Documents. > > The current machine-readable spec of Matroska is available here > > I hope to soon propose changes to this to align it more so with XML Schem= a > practices (i.e. use attributes like minOccurs/maxOccurs instead of the > current mandatory/multiple attributes as well as nesting element > hierarchically). For now I think it would be best to start with this pull > request to start a definition of how to express specifications for EBML > DocTypes and get it in alignment with that current Matroska implementatio= n > of that. > > In this commit > > I removed the `EBML Template` section which was a list of attributes to u= se > to define an EBML Element with very brief descriptions. This is replaced = by > a few paragraphs to introduce the concept of an EBML Schema and then a > table of attributes to define EBML Elements and the definitions of those > attributes. The table is a little hard to read in the pull request but > there is a rendered copy of the table here > > . > > In another commit > I > added a more detailed description of the associated requirements of EBML > Element usage that are conveyed by various combinations of the default an= d > mandatory element. Since this topic has been long discussed and a source = of > confusion, I=E2=80=99d like to be precise here. There seem to be three fa= ctors > involved regarding if a mandatory element should be written to a file or > not (is there a default value declared?, is the value equal to the > default?, and is the parent element used?). I eventually ended up making = a > lookup table > to > say if the Element MUST be written or not. > > Feedback requested. > > Thanks much, > Dave Rice > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --001a11354dda67b395052629e8fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Overall I like it. I've added some questions/nits to t= he GitHub pull request.

On Fri, Dec 4, 2015 at 11:07 PM, Dave Rice &l= t;dave@dericed.com> wrote:
Hi all, but particularly calling out Michael Bradshaw and St= eve Lhomme for a review,

I just submitted a pull request= to the EBML Specification=C2=A0here=C2=A0 The intent is = to offering a description within the EBML Specification regarding to how ma= ke a machine-readable definition of an EBML Document Type. This is a bit an= alogous to saying how to make something like an XML Schema for the Matroska= or webM types of EBML Documents.

The current mach= ine-readable spec of Matroska is available=C2=A0here=C2=A0 I hope to soon= propose changes to this to align it more so with XML Schema practices (i.e= . use attributes like minOccurs/maxOccurs instead of the current mandatory/= multiple attributes as well as nesting element hierarchically). For now I t= hink it would be best to start with this pull request to start a definition= of how to express specifications for EBML DocTypes and get it in alignment= with that current Matroska implementation of that.

In this=C2=A0commit=C2=A0 I removed the `EBML Template` section which was a list of attribute= s to use to define an EBML Element with very brief descriptions. This is re= placed by a few paragraphs to introduce the concept of an EBML Schema and t= hen a table of attributes to define EBML Elements and the definitions of th= ose attributes. The table is a little hard to read in the pull request but = there is a rendered copy of the table=C2=A0here= .

In another=C2=A0commit=C2=A0I added a more detailed description = of the associated requirements of EBML Element usage that are conveyed by v= arious combinations of the default and mandatory element. Since this topic = has been long discussed and a source of confusion, I=E2=80=99d like to be p= recise here. There seem to be three factors involved regarding if a mandato= ry element should be written to a file or not (is there a default value dec= lared?, is the value equal to the default?, and is the parent element used?= ). I eventually ended up making a lookup=C2=A0table=C2=A0to say if the El= ement MUST be written or not.

Feedback requested.<= /div>

Thanks much,
Dave Rice

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


--001a11354dda67b395052629e8fd-- From nobody Sat Dec 5 10:58:53 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821F71B2C71 for ; Sat, 5 Dec 2015 10:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 4Gjagfi7Kxdf for ; Sat, 5 Dec 2015 10:58:47 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA74C1B2C6F for ; Sat, 5 Dec 2015 10:58:47 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:34697 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1a5I2f-002x20-0r; Sat, 05 Dec 2015 13:58:47 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_73C26A8A-E557-4B02-AC6D-20256EA5776C" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dave Rice In-Reply-To: Date: Sat, 5 Dec 2015 13:58:42 -0500 Message-Id: References: <7B3D0399-D9DF-4800-A9B5-7CC6A3180232@dericed.com> To: Michael Bradshaw X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Defining EBML Schema in the EBML spec & mandatory/default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2015 18:58:50 -0000 --Apple-Mail=_73C26A8A-E557-4B02-AC6D-20256EA5776C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, > On Dec 5, 2015, at 12:24 PM, Michael Bradshaw = wrote: >=20 > Overall I like it. I've added some questions/nits to the GitHub pull = request. Thanks for finding the typos.I asked this question via the discussion on = the pull request = , but should = ask here to: The specdata.xml = file is the only precedent = expression of an EBML Schema that I know of. Is there a machine readable = expression of webm anywhere? Or any other EBML Document Type? Considering your points about nailing down the definition of range, = there are only a few range values in use in specdata.xml, =E2=80=9C> = 0=E2=80=9D, =E2=80=9C>0=E2=80=9D, =E2=80=9C0-1=E2=80=9D, =E2=80=9C1-254=E2= =80=9D, and =E2=80=9Cnot 0=E2=80=9D, I made some notes of a definition = of these in a pull request comment = , but propose that ultimately we move the definition of `range` = towards the XML Schema equivalent of `restriction` = . Regarding the conflicts of the spec regarding the meaning of Empty = Elements versus how the default value applies to an Empty Element, I = remember this discussion but forgot about it while drafting. I=E2=80=99ll = add this in shortly, it will be nice to finally have rules about = default/mandatory/empty all centralized as the discussions and clues = have been widespread. Kind Regards, Dave Rice > On Fri, Dec 4, 2015 at 11:07 PM, Dave Rice > wrote: > Hi all, but particularly calling out Michael Bradshaw and Steve Lhomme = for a review, >=20 > I just submitted a pull request to the EBML Specification here = The intent = is to offering a description within the EBML Specification regarding to = how make a machine-readable definition of an EBML Document Type. This is = a bit analogous to saying how to make something like an XML Schema for = the Matroska or webM types of EBML Documents. >=20 > The current machine-readable spec of Matroska is available here = I hope to soon propose = changes to this to align it more so with XML Schema practices (i.e. use = attributes like minOccurs/maxOccurs instead of the current = mandatory/multiple attributes as well as nesting element = hierarchically). For now I think it would be best to start with this = pull request to start a definition of how to express specifications for = EBML DocTypes and get it in alignment with that current Matroska = implementation of that. >=20 > In this commit = I removed the `EBML Template` section which was = a list of attributes to use to define an EBML Element with very brief = descriptions. This is replaced by a few paragraphs to introduce the = concept of an EBML Schema and then a table of attributes to define EBML = Elements and the definitions of those attributes. The table is a little = hard to read in the pull request but there is a rendered copy of the = table here = . >=20 > In another commit = I added a more detailed description of the = associated requirements of EBML Element usage that are conveyed by = various combinations of the default and mandatory element. Since this = topic has been long discussed and a source of confusion, I=E2=80=99d = like to be precise here. There seem to be three factors involved = regarding if a mandatory element should be written to a file or not (is = there a default value declared?, is the value equal to the default?, and = is the parent element used?). I eventually ended up making a lookup = table = to say if the Element = MUST be written or not. >=20 > Feedback requested. >=20 > Thanks much, > Dave Rice >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_73C26A8A-E557-4B02-AC6D-20256EA5776C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Michael,

On Dec 5, 2015, at 12:24 PM, = Michael Bradshaw <mjbshaw@google.com> wrote:

Overall I like it. I've added some questions/nits to the = GitHub pull request.

Thanks for finding the typos.I asked this question = via the discussion on the pull request, but should ask here = to:

The specdata.xml file is the only precedent = expression of an EBML Schema that I know of. Is there a machine = readable expression of webm anywhere? Or any other EBML Document = Type?

Considering your points about = nailing down the definition of range, there are only a few range values = in use in specdata.xml, =E2=80=9C> 0=E2=80=9D, =E2=80=9C>0=E2=80=9D,= =E2=80=9C0-1=E2=80=9D, =E2=80=9C1-254=E2=80=9D, and =E2=80=9Cnot 0=E2=80=9D= , I made some notes of a definition of these in a pull request comment, but propose that ultimately we = move the definition of `range` towards the XML Schema equivalent = of `restriction`.

Regarding the conflicts of the spec regarding the = meaning of Empty Elements versus how the default value applies to an = Empty Element, I remember this discussion but forgot about it while = drafting. I=E2=80=99ll add this in shortly, it will be nice to finally = have rules about default/mandatory/empty all centralized as the = discussions and clues have been widespread.

Kind Regards,
Dave Rice

On Fri, Dec 4, 2015 at = 11:07 PM, Dave Rice <dave@dericed.com> wrote:
Hi all, but particularly = calling out Michael Bradshaw and Steve Lhomme for a review,

I just submitted a pull = request to the EBML Specification here  The intent is to offering a = description within the EBML Specification regarding to how make a = machine-readable definition of an EBML Document Type. This is a bit = analogous to saying how to make something like an XML Schema for the = Matroska or webM types of EBML Documents.

The current machine-readable spec of = Matroska is available here  I hope to soon propose changes to this to = align it more so with XML Schema practices (i.e. use attributes like = minOccurs/maxOccurs instead of the current mandatory/multiple attributes = as well as nesting element hierarchically). For now I think it would be = best to start with this pull request to start a definition of how to = express specifications for EBML DocTypes and get it in alignment with = that current Matroska implementation of that.

In this commit  I removed the `EBML Template` section which = was a list of attributes to use to define an EBML Element with very = brief descriptions. This is replaced by a few paragraphs to introduce = the concept of an EBML Schema and then a table of attributes to define = EBML Elements and the definitions of those attributes. The table is a = little hard to read in the pull request but there is a rendered copy of = the table here.

In another commit I added a more detailed description of the = associated requirements of EBML Element usage that are conveyed by = various combinations of the default and mandatory element. Since this = topic has been long discussed and a source of confusion, I=E2=80=99d = like to be precise here. There seem to be three factors involved = regarding if a mandatory element should be written to a file or not (is = there a default value declared?, is the value equal to the default?, and = is the parent element used?). I eventually ended up making a = lookup table to say if the Element MUST be written or = not.

Feedback = requested.

Thanks much,
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

= --Apple-Mail=_73C26A8A-E557-4B02-AC6D-20256EA5776C-- From nobody Mon Dec 7 09:38:05 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D761AD079 for ; Mon, 7 Dec 2015 09:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 wvz-OeKBtTzk for ; Mon, 7 Dec 2015 09:38:02 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 72B331AD072 for ; Mon, 7 Dec 2015 09:38:02 -0800 (PST) Received: by pabfh17 with SMTP id fh17so131670322pab.0 for ; Mon, 07 Dec 2015 09:38:02 -0800 (PST) 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:content-type; bh=5WSteeiOKh01R5RRyWWoOTGfak4cb+nvOfm2pdeam3w=; b=bTUsLPZZlhcc6ikQ1CUZEvCRa9wHwqZydDvTZUquxufgX4WsIt8jI6lNBgsmM3zS3j XFF6uc8roczGkzTM9rnG/h6yRJTTbIQ9kEt5wi5KCi0DusvZEavEdCcXIuRP1zo0Y2Gs QyWzNG+NTfjVSecdP7hOVE1w6Z+67bkZXi+w/x4mfuzgVv88asZFieJoQypmb4G3W8bm SKyQThroF8ZsI7zdDsqVWduvAmTq9cx7Rx5JJ9frFeXCNpMMJOJgevHErPrOSO2yYbhw Se3va0p2iL4F/a+h1BzLro7V/cKra2R0rsn7ZZwXl20kS9v7qZOXicMU74EktUUlbRq3 BusQ== 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-type; bh=5WSteeiOKh01R5RRyWWoOTGfak4cb+nvOfm2pdeam3w=; b=EX7hwayv0R3D/IZuB9+6mVO3YRQyWWI+FpvMciP1tYkKRPsl/lQ7koE2LZYltci35A 3yQ00v/PKHuGd6s6MkIebjZkh5Zz8dOFXep8/hGyWqj0nsuNGGn5p4El85zxPL8NcyVD S4uMywOWVXPZA1oiUjvzmbDJGajaGttSLOmA+4Use9SkhsTvZpDfBw7nPfuPd5t4gknR BMFe7mbqHwbAB7lvknGOArJDb0y45Zl0ozAzRTm6pbN7xMSc1v9ZdpIzVl7mMVTiJYrX x0H73D90G17iKcCG5Los4W3mP2bd+mT8RzBIPD5gzmjOP8OnQ/flR1pILwMQramFAnjD vrMQ== X-Gm-Message-State: ALoCoQlfadAIg3WsnecCvmhdupIa1JsruybB5GCPAOqtQQaD5vx6/vk2i1HJYDb6gK3JL9VXFWg5 X-Received: by 10.66.194.198 with SMTP id hy6mr45471311pac.34.1449509882067; Mon, 07 Dec 2015 09:38:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.156.165 with HTTP; Mon, 7 Dec 2015 09:37:42 -0800 (PST) In-Reply-To: References: <7B3D0399-D9DF-4800-A9B5-7CC6A3180232@dericed.com> From: Michael Bradshaw Date: Mon, 7 Dec 2015 09:37:42 -0800 Message-ID: To: Dave Rice Content-Type: multipart/alternative; boundary=001a1133c9909ee62d052652513b Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Defining EBML Schema in the EBML spec & mandatory/default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 07 Dec 2015 17:38:04 -0000 --001a1133c9909ee62d052652513b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 5, 2015 at 10:58 AM, Dave Rice wrote: > > The specdata.xml > file is > the only precedent expression of an EBML Schema that I know of. Is there = a > machine readable expression of webm anywhere? Or any other EBML Document > Type? > Not that I know of (there certainly isn't anything normative like that for WebM). I'm really looking forward to a standardized machine readable form, because it'll help keep the WebM and MKV specs consistent. Right now they've fallen out of sync (i.e. WebM marks several elements as supported, like BlockVirtual, BlockAdditions, MaxBlockAdditionID, etc that aren't marked as supported in WebM within the MKV spec). Considering your points about nailing down the definition of range, there > are only a few range values in use in specdata.xml, =E2=80=9C> 0=E2=80=9D= , =E2=80=9C>0=E2=80=9D, =E2=80=9C0-1=E2=80=9D, > =E2=80=9C1-254=E2=80=9D, and =E2=80=9Cnot 0=E2=80=9D, I made some notes o= f a definition of these in a pull > request comment > , > but propose that ultimately we move the definition of `range` towards the > XML Schema equivalent of `restriction` > . > Something along the lines of XML Schema restriction would probably be nice, because then you could use it for strings and the like. > Regarding the conflicts of the spec regarding the meaning of Empty > Elements versus how the default value applies to an Empty Element, I > remember this discussion but forgot about it while drafting. I=E2=80=99ll= add this > in shortly, it will be nice to finally have rules about > default/mandatory/empty all centralized as the discussions and clues have > been widespread. > Great, looking forward to that. I'll review that when it's up. --001a1133c9909ee62d052652513b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Dec 5, 2015 at 10:58 AM, Dave Rice <dave@dericed.com> wro= te:
The= =C2=A0specdata.xml=C2=A0file=C2=A0is the only precedent expression of an = EBML Schema that I know of. Is=C2=A0there a machine readable expression of = webm anywhere? Or any other EBML=C2=A0Document Type?

Not that I know of (there certainly isn&#= 39;t anything normative like that for WebM). I'm really looking forward= to a standardized machine readable form, because it'll help keep the W= ebM and MKV specs consistent. Right now they've fallen out of sync (i.e= . WebM marks several elements as supported, like=C2=A0BlockVirtual, BlockAd= ditions,=C2=A0MaxBlockAdditionID, etc that aren't marked as supported i= n WebM within the MKV spec).

Considering your points about nai= ling down the definition of range, there are only a few range values in use= in specdata.xml, =E2=80=9C> 0=E2=80=9D, =E2=80=9C>0=E2=80=9D, =E2=80= =9C0-1=E2=80=9D, =E2=80=9C1-254=E2=80=9D, and =E2=80=9Cnot 0=E2=80=9D, I ma= de some notes of a definition of these in a pull request=C2=A0comment, but propose that ultimately we move the = definition of `range` towards the XML Schema equivalent of=C2=A0`restrict= ion`.

Something= along the lines of XML Schema restriction would probably be nice, because = then you could use it for strings and the like.
=C2=A0
Regarding th= e conflicts of the spec regarding the meaning of Empty Elements versus how = the default value applies to an Empty Element, I remember this discussion b= ut forgot about it while drafting. I=E2=80=99ll add this in shortly, it wil= l be nice to finally have rules about default/mandatory/empty all centraliz= ed as the discussions and clues have been widespread.

Great, looking forward to that. I'll= review that when it's up.=C2=A0
--001a1133c9909ee62d052652513b-- From nobody Mon Dec 7 10:05:06 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6801B38B9 for ; Mon, 7 Dec 2015 10:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 5V33nGev5H-F for ; Mon, 7 Dec 2015 10:05:02 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A211AD2EE for ; Mon, 7 Dec 2015 10:05:02 -0800 (PST) Received: from [146.96.19.240] (port=17854 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1a609j-000AvH-H6; Mon, 07 Dec 2015 13:05:00 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_700CDFC3-3D9D-4C36-AEB8-D30CEC3789A3" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Dave Rice In-Reply-To: Date: Mon, 7 Dec 2015 13:04:57 -0500 Message-Id: References: <7B3D0399-D9DF-4800-A9B5-7CC6A3180232@dericed.com> To: Michael Bradshaw , Steve Lhomme X-Mailer: Apple Mail (2.1990.1) X-OutGoing-Spam-Status: No, score=-1.0 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-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Discussion about the current and future development of Matroska , cellar@ietf.org Subject: Re: [Cellar] Defining EBML Schema in the EBML spec & mandatory/default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 07 Dec 2015 18:05:04 -0000 --Apple-Mail=_700CDFC3-3D9D-4C36-AEB8-D30CEC3789A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, > On Dec 7, 2015, at 12:37 PM, Michael Bradshaw = wrote: >=20 > On Sat, Dec 5, 2015 at 10:58 AM, Dave Rice > wrote: > The specdata.xml = file is the only precedent = expression of an EBML Schema that I know of. Is there a machine readable = expression of webm anywhere? Or any other EBML Document Type? >=20 > Not that I know of (there certainly isn't anything normative like that = for WebM). I'm really looking forward to a standardized machine readable = form, because it'll help keep the WebM and MKV specs consistent. Right = now they've fallen out of sync (i.e. WebM marks several elements as = supported, like BlockVirtual, BlockAdditions, MaxBlockAdditionID, etc = that aren't marked as supported in WebM within the MKV spec). >=20 > Considering your points about nailing down the definition of range, = there are only a few range values in use in specdata.xml, =E2=80=9C> = 0=E2=80=9D, =E2=80=9C>0=E2=80=9D, =E2=80=9C0-1=E2=80=9D, =E2=80=9C1-254=E2= =80=9D, and =E2=80=9Cnot 0=E2=80=9D, I made some notes of a definition = of these in a pull request comment = , but propose that ultimately we move the definition of `range` = towards the XML Schema equivalent of `restriction` = . >=20 > Something along the lines of XML Schema restriction would probably be = nice, because then you could use it for strings and the like. One caution I have here is that the current specdata.xml file is used to = create libraries that are used to build mkvalidator. I think possibly a = different specdata.xml could be used to create a validator from = mkvalidator code for another EBML format. However, mkvalidator likely = does not support much outside of the current `range` values. If we use = something broader like XML Schema's restriction we could end up making = EBML Schemas that can not be used within mkvalidator. On the other hand, = support for string restrictions would allow us to have a = machine-readable test on Matroska tags, whereas we=20 If we standardize EBML Schema, I think it's practically essential to = have a utility that can use the EBML Schema to validate an EBML = Document. To do that there is mkvalidator and inside the PreForma = project there is work underway to build an EBML validator using a = combination of MediaTrace and XSL. Cc'ing matroska-devel on this, but I like to ask: If EBML Schema is extended to support more comprehensive expressions = that specdata.xml currently supports, are there volunteers to update = mkvalidator to support the new EBML Schema? I can volunteer to update = data2spec to produce a similar output but feasibly our work on EBML = Schema may mean that it then continues unpredicted expressions. An alternate could be to say that EBML Schema has X features but that = the Matroska specification adds T constraints onto the implementation of = the schema, so that the only Matroska EBML Schema is semantically = equivalent to specdata.xml > Regarding the conflicts of the spec regarding the meaning of Empty = Elements versus how the default value applies to an Empty Element, I = remember this discussion but forgot about it while drafting. I=E2=80=99ll = add this in shortly, it will be nice to finally have rules about = default/mandatory/empty all centralized as the discussions and clues = have been widespread. >=20 > Great, looking forward to that. I'll review that when it's up. I'll probably do this by adding another paragraph and then another = column that that lookup table that I started. Best Regards, Dave Rice --Apple-Mail=_700CDFC3-3D9D-4C36-AEB8-D30CEC3789A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Michael,

On Dec 7, 2015, at 12:37 PM, = Michael Bradshaw <mjbshaw@google.com> wrote:

On Sat, = Dec 5, 2015 at 10:58 AM, Dave Rice <dave@dericed.com> wrote:
The specdata.xml file is the only precedent = expression of an EBML Schema that I know of. Is there a machine = readable expression of webm anywhere? Or any other EBML Document = Type?

Not that I know of (there certainly = isn't anything normative like that for WebM). I'm really looking forward = to a standardized machine readable form, because it'll help keep the = WebM and MKV specs consistent. Right now they've fallen out of sync = (i.e. WebM marks several elements as supported, like BlockVirtual, = BlockAdditions, MaxBlockAdditionID, etc that aren't marked as = supported in WebM within the MKV spec).

Considering = your points about nailing down the definition of range, there are only a = few range values in use in specdata.xml, =E2=80=9C> 0=E2=80=9D, = =E2=80=9C>0=E2=80=9D, =E2=80=9C0-1=E2=80=9D, =E2=80=9C1-254=E2=80=9D, = and =E2=80=9Cnot 0=E2=80=9D, I made some notes of a definition of these = in a pull request comment, but propose = that ultimately we move the definition of `range` towards the XML Schema = equivalent of `restriction`.

Something along the = lines of XML Schema restriction would probably be nice, because then you = could use it for strings and the = like.

One caution I have here is that the current = specdata.xml file is used to create libraries that are used to build = mkvalidator. I think possibly a different specdata.xml could be used to = create a validator from mkvalidator code for another EBML format. = However, mkvalidator likely does not support much outside of the current = `range` values. If we use something broader like XML Schema's = restriction we could end up making EBML Schemas that can not be used = within mkvalidator. On the other hand, support for string restrictions = would allow us to have a machine-readable test on Matroska tags, whereas = we 

If we standardize EBML = Schema, I think it's practically essential to have a utility that can = use the EBML Schema to validate an EBML Document. To do that there is = mkvalidator and inside the PreForma project there is work underway to = build an EBML validator using a combination of MediaTrace and = XSL.

Cc'ing matroska-devel on this, = but I like to ask:
If EBML Schema is extended to support more = comprehensive expressions that specdata.xml currently supports, are = there volunteers to update mkvalidator to support the new EBML Schema? I = can volunteer to update data2spec to produce a similar output but = feasibly our work on EBML Schema may mean that it then continues = unpredicted expressions.

An = alternate could be to say that EBML Schema has X features but that the = Matroska specification adds T constraints onto the implementation of the = schema, so that the only Matroska EBML Schema is semantically equivalent = to specdata.xml

Regarding the = conflicts of the spec regarding the meaning of Empty Elements versus how = the default value applies to an Empty Element, I remember this = discussion but forgot about it while drafting. I=E2=80=99ll add this in = shortly, it will be nice to finally have rules about = default/mandatory/empty all centralized as the discussions and clues = have been widespread.

Great, looking forward = to that. I'll review that when it's up.

I'll probably do this by = adding another paragraph and then another column that that lookup table = that I started.
Best Regards,
Dave Rice

= --Apple-Mail=_700CDFC3-3D9D-4C36-AEB8-D30CEC3789A3-- From nobody Tue Dec 8 01:12:18 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6677A1A913A for ; Tue, 8 Dec 2015 01:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 k062iJ9yD1xg for ; Tue, 8 Dec 2015 01:12:15 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 9C8E11A9139 for ; Tue, 8 Dec 2015 01:12:15 -0800 (PST) Received: by vkca188 with SMTP id a188so8247639vkc.0 for ; Tue, 08 Dec 2015 01:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qzvx2GjbQ5MI6vJmgDiJB+v/XEA92WdvftLzIhP8NVk=; b=nk/N26jwabQ4c/IUZvnT6KoeFf2l0h47lpQ75bbHwuBXtrK3I6Vjuox3qLxbsZmY7Q HZ9p3/9Qug/Mxtu8oeDCsV4w3bBYr/7MARLIAtnUa6GzdKTVBpXPpSgBlNRc9papVVWR PARZYdVk/mqVvr+c3VyMzFOxuJ3uf+NAwJvPz6uUkgRiyppp9Ht5b8ChcW4yRbvfEmoU /D8i2DGE/R0uzUtTYPK0PzpcgjlGQJrMN45oEwwubfezNTlc2wDuSOCJ4tLvPv+DqpLs yzWeo0HNe0uPIBJbVkCCLRCgJHTyNlGaPamhWOYadGg1pmkC5leVurh8xzOIaxeR6GQK Jcog== 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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qzvx2GjbQ5MI6vJmgDiJB+v/XEA92WdvftLzIhP8NVk=; b=ZuuBZoX5A1z8fQHGE+5poUAMRjhYSR8T2c/gn0SREWIQSBW9hUL/iUHtnaYnSYnXMf gcREh4XtKqfP82oyvcibMxICdDE7w81q+vIkTMit2t+3e0wuELzD3LvGPJfCHrtKxFk5 HwOXbCa/udFQezotSXAkfB62h/CwXLKYWWFv7zp2Hjzd3yqzpRy6xiF+nkE2R38hoi9t mZ0q0cuz/sJRTjybdZ7EAEXU2HxtLyQvroJMadbK8SnxTTC+I1C6Ahemv50L4nQ1coI7 w4gW5qqcEnJBRk9g7wvlT+r3AI0qG9ArfX0wUCtLeDqLNZbI617qrsVOgb/FzvlhmUgf RdAg== X-Gm-Message-State: ALoCoQlOvR99kCXao5vSoMGq3H5iF+S52OGv9TeqESkJvGiBTka1HIAMvZe+o4FZUK+yAHWwxJbU8k2L5unsC5trKtD0/eu+8g== MIME-Version: 1.0 X-Received: by 10.31.135.2 with SMTP id j2mr2193364vkd.91.1449565934751; Tue, 08 Dec 2015 01:12:14 -0800 (PST) Received: by 10.31.15.12 with HTTP; Tue, 8 Dec 2015 01:12:14 -0800 (PST) In-Reply-To: References: <21E28D45-E45F-4CBE-AC3D-6E41DCE172B9@dericed.com> <20150828065002.GH3813@bunkus.org> <5606B89B-FCF0-4C75-BAB8-FB1E212F8D82@dericed.com> <5EDBE9D2-3E2F-4865-ACF9-497706E0CA07@dericed.com> <20151201160101.GZ2936@bunkus.org> Date: Tue, 8 Dec 2015 10:12:14 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org, Moritz Bunkus , Discussion about the current and future development of Matroska Subject: Re: [Cellar] [Matroska-devel] EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2015 09:12:17 -0000 2015-12-04 0:50 GMT+01:00 Dave Rice : > Thanks Moritz, >> On Dec 1, 2015, at 11:01 AM, Moritz Bunkus wrote: >> >> Hey, >> >>> I=E2=80=99m preparing a pull request on specdata.xml but want to update= the >>> utilities in spectool at the same time so that spec2data, data2lib, >>> and data2spec still function properly. I=E2=80=99m having trouble getti= ng the >>> spectool utilities to build properly so that I can test them. >> >> All of that is Steve's code and I don't know a lot about coremake and >> the assorted build process (and there's zero documentation), but I do >> manage to get it to compile most of the time ;) >> >> From a fresh checkout of the foundation repository[1] in ~/foundation: >> >> -------------------- >> >> 1. Build and install coremake: >> >> cd ~/foundationcorec/tools/coremake >> make >> make install >> >> Unfortunately coremake has /usr/local/share/coremake hardcoded on Linux >> for looking up its include files; therefore the "make install" is >> actually really necessary. >> >> 2. Configure the rest of the project with coremake: >> >> cd ~/foundation >> coremake gcc_linux_x64 >> >> 3. Compile the tools (mkvtree, mkvalidator, mkclean; optional): >> >> cd ~/foundation >> make >> >> 4. Compile the programs in spectool: >> >> cd ~/foundation >> make -C spectool >> >> 5. Use the programs: >> >> # This creates spec.xml from specdata.xml. spec.xml is basically the >> # HTML table you see on www.matroska.org/technical/specs/: >> >> cd ~/foundation/spectools >> ../release/gcc_linux_x64/data2spec >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 > > These instructions worked well. To help the next person who happens along= , I converted your notes into a basic README which I sent as a pull request= here: https://github.com/Matroska-Org/foundation-source/pull/6. > >>> I was able to build coremake but not sure where to go from here. >> >> The whole foundation repo could use a serious rewrite of its build >> system. Steve had reasons why he created coremake, but the result is >> very, very complicated to use. If you (or anyone else) want to give such >> a rewrite a try I'd highly welcome it. > > I am interested in the foundation repo since it is the home of the Matros= ka instance of the basis of the conceptual EBML Schema (specdata.xml). To w= ork on moving the current state of specdata.xml towards a more standardized= EBML Schema expression I should synchronize the work on specdata.xml to th= e spectools so that the foundation repo doesn=E2=80=99t break because of IE= TF work. > > The rest of the foundation repo may be out of scope to the charter. There= is obviously a lot of documentation on Matroska use on matroska.org but th= at appears to be based in your Drupal site rather than this repo. If you're referring to the documentation in the HTML tables on matroska.org, they are taken from the specdata.xml after the HTML is generated, not the other way around. > I think we still need a good method to handle linking pull requests, comm= ents, and discussion upon the Matroska documentation. Drupal makes this a b= it difficult. Should we move some of this documentation to GitHub as well a= nd have a similar process as spec.xml with the other documentation (i.e. bu= ild it from a repo and copy/paste it to Drupal). Or potentially we could mo= ve some Matroska documentation from Drupal to GitHub gh-pages as done with = the EBML Specification website (formerly on sourceforge). I agree, it will be much easier to do things on Github. >>> Any advice on which route to take: continue trying with getting >>> spectool utilities to build or redo the utilities in xsl? >> >> I'd prefer established technologies like XSLT in this case as it allows >> you to use a plethora of proven tools like xsltproc or any other XSLT >> processor (Saxon?). You can (and should) still build the tools with the >> instructions above so that you verify stuff works :) > > This is verified. If XSLT is welcome I certainly think it=E2=80=99s much = more familiar. Not to me, but it shouldn't too hard to adapt the spec tools to match field name changes at the same time. If XSLT can also generate the C/C++ code matching the semantics, then it's great. That should make it easier for people to create their own EBML format and play with the code while defining it. > Thanks, > Dave Rice > >> Kind regards, >> mosu >> >> [1] https://github.com/Matroska-Org/foundation-source/ >> _______________________________________________ >> 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 Tue Dec 8 01:15:41 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B091A9151 for ; Tue, 8 Dec 2015 01:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 dG4FD1bV7DGg for ; Tue, 8 Dec 2015 01:15:38 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9F21A9150 for ; Tue, 8 Dec 2015 01:15:38 -0800 (PST) Received: by vkha189 with SMTP id a189so8175289vkh.2 for ; Tue, 08 Dec 2015 01:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nvOx8yTTEfwFnL4/i2QHLq6up0mfPiqdAjJk9X72280=; b=cS2fbDvHTmXULrMd/kkfylDFtF9lW60zc2ew//Dhy4BI+7i+Yl4iiONIong5ZoEeRc fxMl39F3VUIk8rIRTm71RQVVJNRa+EYh7ANbNKF2PcOg0qBs+kLBy9/spsM8Ci13E8pI 3olsss+If9ctQYY7FoA/xwfOamyQrKDuLEI25CE7zUymYp7v/MNfIiJEiJbRbwW7Mran sofD3VXxVx7ZzlLNbiLMsJXjA5rwYocm8E2yY3cP8emby/DvgGIafKgOTPGYKceJo5pQ 9oxj2M/jGoeAucxJfpn3tNskDUouw0Ze4fzJGIBTvbUgujGXcJwDc2LjD03Ww4jgSQv8 GOHg== 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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nvOx8yTTEfwFnL4/i2QHLq6up0mfPiqdAjJk9X72280=; b=C38O3c58Yg/2xKMgoZbE+MtamSYpRIUPM2Rxs5R05PzwHRxAPp3h8Su4E4bvQCq+Nh inXmBLXQXAEwqR0UCuCAksTD5r0oPuf90aYkyML8lMQlh6ywptrJ56PsTgAVwB8BA7br 1nfArxS0DJwhNyXXkDrc7RH5IU7hE6kwojD5iKyJS3dSe/O95Ceh4NYyKVe8vUAr+QFE o0Z2hNsH2i2dInU0sBw7euFvtxA7Bk6RzBXtNOmg5er86Npor7+ry/YKQWIeQ8W+BMZv FcnsqcMaXgLDhm6CbVILLMz3H+h7oz1QbXsnW64DH18Qqrz1oFHDPtx2rxGxFY08syg5 U4ew== X-Gm-Message-State: ALoCoQn5OQKjp/UScLM9Ku/Wog1ig4VLp5pg6Z437TOzdrCVxRysDcQLB01d4D/FwsmlrXQTuNEo4loQK9gZzeaPzng6sW4VZw== MIME-Version: 1.0 X-Received: by 10.31.60.4 with SMTP id j4mr1673018vka.109.1449566136529; Tue, 08 Dec 2015 01:15:36 -0800 (PST) Received: by 10.31.15.12 with HTTP; Tue, 8 Dec 2015 01:15:36 -0800 (PST) In-Reply-To: References: <7B3D0399-D9DF-4800-A9B5-7CC6A3180232@dericed.com> Date: Tue, 8 Dec 2015 10:15:36 +0100 Message-ID: From: Steve Lhomme To: Michael Bradshaw Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Dave Rice , cellar@ietf.org Subject: Re: [Cellar] Defining EBML Schema in the EBML spec & mandatory/default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2015 09:15:39 -0000 2015-12-07 18:37 GMT+01:00 Michael Bradshaw : > On Sat, Dec 5, 2015 at 10:58 AM, Dave Rice wrote: >> >> The specdata.xml file is the only precedent expression of an EBML Schema >> that I know of. Is there a machine readable expression of webm anywhere?= Or >> any other EBML Document Type? > > > Not that I know of (there certainly isn't anything normative like that fo= r > WebM). I'm really looking forward to a standardized machine readable form= , > because it'll help keep the WebM and MKV specs consistent. Right now they= 've > fallen out of sync (i.e. WebM marks several elements as supported, like > BlockVirtual, BlockAdditions, MaxBlockAdditionID, etc that aren't marked = as > supported in WebM within the MKV spec). We might take this in consideration in the XML Schema definition: how to we define different formats based on the same core of fields. That applies to Matroska versions as well. I do not have an answer to that. >> Considering your points about nailing down the definition of range, ther= e >> are only a few range values in use in specdata.xml, =E2=80=9C> 0=E2=80= =9D, =E2=80=9C>0=E2=80=9D, =E2=80=9C0-1=E2=80=9D, >> =E2=80=9C1-254=E2=80=9D, and =E2=80=9Cnot 0=E2=80=9D, I made some notes = of a definition of these in a pull >> request comment, but propose that ultimately we move the definition of >> `range` towards the XML Schema equivalent of `restriction`. > > > Something along the lines of XML Schema restriction would probably be nic= e, > because then you could use it for strings and the like. > >> >> Regarding the conflicts of the spec regarding the meaning of Empty >> Elements versus how the default value applies to an Empty Element, I >> remember this discussion but forgot about it while drafting. I=E2=80=99l= l add this >> in shortly, it will be nice to finally have rules about >> default/mandatory/empty all centralized as the discussions and clues hav= e >> been widespread. > > > Great, looking forward to that. I'll review that when it's up. > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Tue Dec 8 01:20:19 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F54A1A9173 for ; Tue, 8 Dec 2015 01:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 295A4ByekYHw for ; Tue, 8 Dec 2015 01:20:07 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FCE1A9238 for ; Tue, 8 Dec 2015 01:20:07 -0800 (PST) Received: by vkca188 with SMTP id a188so8348489vkc.0 for ; Tue, 08 Dec 2015 01:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ojr4iisCKDyXUErWN1+zb+9FDwS+cjHjaIF2DC54duo=; b=tUshmUd8euKTtczUPHgluUcz6dwO2kVP8bqKHJuJlp7rUJwCHtPlfQNf43Pg3otPfZ 7LoBqjYE2+FlAOjwFiYU/ycjf/C0035wfjd2jzdVYkVuJKrP0CZ/csHG/jmYV5Z5O7/0 EufpSvsZ6rZ36XcP9UibpFtaFaRsIdS7zMzZCJ5cL1rjzz8OAa/X7k656AstFzazZBHL fCQG8CjLrGvxF0jZFILzTmpp8VZ5HO4OsSGCJ+xeHcBC/0ruVVEivm38ctEYo2bnAoGr iN82vb/DiS6yCB5xyBh3lvJznf6Jdz5muXHBe0IY2GV/L/fAdcEiOBU3cSgNsXQsJnYG skZQ== 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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ojr4iisCKDyXUErWN1+zb+9FDwS+cjHjaIF2DC54duo=; b=NHN1Bu7C1X/FjLvpyUZ6RCtDbmdy35eeI8K+xRGSMQs8hi0JzU6zUaKGCByLJIhR45 TJgUkqJZIKgW2GkRcV83C4WUp0Mqki3scvVE6jrNgysyuVo8+45Gn21Ug5CelvxsCRxy yykbx6/DJLWdrRDnEwbGraweZ5XxVVttwfXD6ScPF9Ia2pBDJ/JZ9CrAZaEvIP47QtI2 njpNSu62nZO5X/YORnLM10M71CTIAX0WhZoA9Q3BbIFnjH7NpjblhbR6bBZEf2i7/irP SDWGjoCJmEiAW9kxBij7M2oXtUqeaN/FK6Pwl5TYYXdbEK5awD4Lhm/iNlMZp00HSyEX KQxA== X-Gm-Message-State: ALoCoQla9quDNDkrsMcyhCc3dWza959Ealke8Gf1p5MLnAsIgAFB4kMf+u7FcYIa7T06UCqVPx6MHt7vXdbx/bTeywjcflJzHQ== MIME-Version: 1.0 X-Received: by 10.31.54.78 with SMTP id d75mr2291556vka.122.1449566406301; Tue, 08 Dec 2015 01:20:06 -0800 (PST) Received: by 10.31.15.12 with HTTP; Tue, 8 Dec 2015 01:20:06 -0800 (PST) In-Reply-To: References: <7B3D0399-D9DF-4800-A9B5-7CC6A3180232@dericed.com> Date: Tue, 8 Dec 2015 10:20:06 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Discussion about the current and future development of Matroska , Michael Bradshaw , cellar@ietf.org Subject: Re: [Cellar] Defining EBML Schema in the EBML spec & mandatory/default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2015 09:20:08 -0000 2015-12-07 19:04 GMT+01:00 Dave Rice : > Hi Michael, > > On Dec 7, 2015, at 12:37 PM, Michael Bradshaw wrote: > > On Sat, Dec 5, 2015 at 10:58 AM, Dave Rice wrote: >> >> The specdata.xml file is the only precedent expression of an EBML Schema >> that I know of. Is there a machine readable expression of webm anywhere?= Or >> any other EBML Document Type? > > > Not that I know of (there certainly isn't anything normative like that fo= r > WebM). I'm really looking forward to a standardized machine readable form= , > because it'll help keep the WebM and MKV specs consistent. Right now they= 've > fallen out of sync (i.e. WebM marks several elements as supported, like > BlockVirtual, BlockAdditions, MaxBlockAdditionID, etc that aren't marked = as > supported in WebM within the MKV spec). > >> Considering your points about nailing down the definition of range, ther= e >> are only a few range values in use in specdata.xml, =E2=80=9C> 0=E2=80= =9D, =E2=80=9C>0=E2=80=9D, =E2=80=9C0-1=E2=80=9D, >> =E2=80=9C1-254=E2=80=9D, and =E2=80=9Cnot 0=E2=80=9D, I made some notes = of a definition of these in a pull >> request comment, but propose that ultimately we move the definition of >> `range` towards the XML Schema equivalent of `restriction`. > > > Something along the lines of XML Schema restriction would probably be nic= e, > because then you could use it for strings and the like. > > > One caution I have here is that the current specdata.xml file is used to > create libraries that are used to build mkvalidator. I think possibly a > different specdata.xml could be used to create a validator from mkvalidat= or > code for another EBML format. However, mkvalidator likely does not suppor= t > much outside of the current `range` values. If we use something broader l= ike > XML Schema's restriction we could end up making EBML Schemas that can not= be > used within mkvalidator. On the other hand, support for string restrictio= ns > would allow us to have a machine-readable test on Matroska tags, whereas = we > > If we standardize EBML Schema, I think it's practically essential to have= a > utility that can use the EBML Schema to validate an EBML Document. To do > that there is mkvalidator and inside the PreForma project there is work > underway to build an EBML validator using a combination of MediaTrace and > XSL. If we go the XSLT way, I suppose a more flexible validator could be written using that and be easily updated on the fly, compared to a compile program like mkvalidator. > Cc'ing matroska-devel on this, but I like to ask: > If EBML Schema is extended to support more comprehensive expressions that > specdata.xml currently supports, are there volunteers to update mkvalidat= or > to support the new EBML Schema? I can volunteer to update data2spec to > produce a similar output but feasibly our work on EBML Schema may mean th= at > it then continues unpredicted expressions. I will continue maintaining mkvalidator, until another validator supports all the same error/warning detections and profiles (live, webm, divx). > An alternate could be to say that EBML Schema has X features but that the > Matroska specification adds T constraints onto the implementation of the > schema, so that the only Matroska EBML Schema is semantically equivalent = to > specdata.xml > >> Regarding the conflicts of the spec regarding the meaning of Empty >> Elements versus how the default value applies to an Empty Element, I >> remember this discussion but forgot about it while drafting. I=E2=80=99l= l add this >> in shortly, it will be nice to finally have rules about >> default/mandatory/empty all centralized as the discussions and clues hav= e >> been widespread. > > > Great, looking forward to that. I'll review that when it's up. > > > I'll probably do this by adding another paragraph and then another column > that that lookup table that I started. > Best Regards, > Dave Rice > --=20 Steve Lhomme Matroska association Chairman From nobody Tue Dec 8 05:17:14 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B5A1B2D7E for ; Tue, 8 Dec 2015 05:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_43=1, SPF_NEUTRAL=0.779] autolearn=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 qoP5QiCVENG2 for ; Tue, 8 Dec 2015 05:17:10 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7E81B2AFC for ; Tue, 8 Dec 2015 05:17:10 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:33646 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1a6I8h-001Bnw-TO; Tue, 08 Dec 2015 08:17:09 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dave Rice In-Reply-To: Date: Tue, 8 Dec 2015 08:17:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <98E71C27-BF0D-4F8F-9E00-FFC69540C74C@dericed.com> References: <7B3D0399-D9DF-4800-A9B5-7CC6A3180232@dericed.com> To: Steve Lhomme X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Discussion about the current and future development of Matroska , Michael Bradshaw , cellar@ietf.org Subject: Re: [Cellar] Defining EBML Schema in the EBML spec & mandatory/default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2015 13:17:12 -0000 > On Dec 8, 2015, at 4:20 AM, Steve Lhomme wrote: >=20 > 2015-12-07 19:04 GMT+01:00 Dave Rice : >>=20 >> On Dec 7, 2015, at 12:37 PM, Michael Bradshaw = wrote: [=E2=80=A6] >> One caution I have here is that the current specdata.xml file is used = to >> create libraries that are used to build mkvalidator. I think possibly = a >> different specdata.xml could be used to create a validator from = mkvalidator >> code for another EBML format. However, mkvalidator likely does not = support >> much outside of the current `range` values. If we use something = broader like >> XML Schema's restriction we could end up making EBML Schemas that can = not be >> used within mkvalidator. On the other hand, support for string = restrictions >> would allow us to have a machine-readable test on Matroska tags, = whereas we >>=20 >> If we standardize EBML Schema, I think it's practically essential to = have a >> utility that can use the EBML Schema to validate an EBML Document. To = do >> that there is mkvalidator and inside the PreForma project there is = work >> underway to build an EBML validator using a combination of MediaTrace = and >> XSL. >=20 > If we go the XSLT way, I suppose a more flexible validator could be > written using that and be easily updated on the fly, compared to a > compile program like mkvalidator. >=20 >> Cc'ing matroska-devel on this, but I like to ask: >> If EBML Schema is extended to support more comprehensive expressions = that >> specdata.xml currently supports, are there volunteers to update = mkvalidator >> to support the new EBML Schema? I can volunteer to update data2spec = to >> produce a similar output but feasibly our work on EBML Schema may = mean that >> it then continues unpredicted expressions. >=20 > I will continue maintaining mkvalidator, until another validator > supports all the same error/warning detections and profiles (live, > webm, divx). Thanks Steve. I realize that another approach we could use is to convert EBML to XML = and then validate the resulting XML with an XML Schema that defines an = EBML format. This would means that we could use any XML validator = instead of necessarily needing a custom EBML validator. There is already = an EBML<->XML converter here https://github.com/vi/mkvparse/. An EBML = validator could work like this: mkv2xml < test.mkv > output.xml xmllint --noout --schema output.xml I note that mkvalidator has some tests that are analogous to XML = validation against an XML Schema, but some are rules more similar to = Schematron. I=E2=80=99ll have to see if these rules could possibly to = stored properly in an XML Schema to verify if we=E2=80=99d need a second = schematron-like test. Ideas? re: Updating mkvalidator to validate an EBML Dcoument validator = against an EBML Schema. Or. Using existing XML validation tools with an = EBML->XML conversion? Dave= From nobody Thu Dec 10 05:03:24 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266911A1B86 for ; Thu, 10 Dec 2015 05:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.579 X-Spam-Level: ** X-Spam-Status: No, score=2.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_BACKHAIR_43=1, SPF_NEUTRAL=0.779] autolearn=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 sR9hwtxqWeO1 for ; Thu, 10 Dec 2015 05:03:09 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E070C1B2B38 for ; Thu, 10 Dec 2015 05:02:34 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:47972 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1a70rg-001CyR-U2; Thu, 10 Dec 2015 08:02:33 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dave Rice In-Reply-To: <98E71C27-BF0D-4F8F-9E00-FFC69540C74C@dericed.com> Date: Thu, 10 Dec 2015 08:02:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2FC0514F-5868-4178-9554-250CC8D8AFD3@dericed.com> References: <7B3D0399-D9DF-4800-A9B5-7CC6A3180232@dericed.com> <98E71C27-BF0D-4F8F-9E00-FFC69540C74C@dericed.com> To: cellar@ietf.org X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Discussion about the current and future development of Matroska Subject: Re: [Cellar] Defining EBML Schema in the EBML spec & mandatory/default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 13:03:13 -0000 Hi all, > On Dec 8, 2015, at 8:17 AM, Dave Rice wrote: >=20 >=20 >> On Dec 8, 2015, at 4:20 AM, Steve Lhomme = wrote: >>=20 >> 2015-12-07 19:04 GMT+01:00 Dave Rice : >>>=20 >>> On Dec 7, 2015, at 12:37 PM, Michael Bradshaw = wrote: >=20 > [=E2=80=A6] >=20 >>> One caution I have here is that the current specdata.xml file is = used to >>> create libraries that are used to build mkvalidator. I think = possibly a >>> different specdata.xml could be used to create a validator from = mkvalidator >>> code for another EBML format. However, mkvalidator likely does not = support >>> much outside of the current `range` values. If we use something = broader like >>> XML Schema's restriction we could end up making EBML Schemas that = can not be >>> used within mkvalidator. On the other hand, support for string = restrictions >>> would allow us to have a machine-readable test on Matroska tags, = whereas we >>>=20 >>> If we standardize EBML Schema, I think it's practically essential to = have a >>> utility that can use the EBML Schema to validate an EBML Document. = To do >>> that there is mkvalidator and inside the PreForma project there is = work >>> underway to build an EBML validator using a combination of = MediaTrace and >>> XSL. >>=20 >> If we go the XSLT way, I suppose a more flexible validator could be >> written using that and be easily updated on the fly, compared to a >> compile program like mkvalidator. >>=20 >>> Cc'ing matroska-devel on this, but I like to ask: >>> If EBML Schema is extended to support more comprehensive expressions = that >>> specdata.xml currently supports, are there volunteers to update = mkvalidator >>> to support the new EBML Schema? I can volunteer to update data2spec = to >>> produce a similar output but feasibly our work on EBML Schema may = mean that >>> it then continues unpredicted expressions. >>=20 >> I will continue maintaining mkvalidator, until another validator >> supports all the same error/warning detections and profiles (live, >> webm, divx). >=20 > Thanks Steve. >=20 > I realize that another approach we could use is to convert EBML to XML = and then validate the resulting XML with an XML Schema that defines an = EBML format. This would means that we could use any XML validator = instead of necessarily needing a custom EBML validator. There is already = an EBML<->XML converter here https://github.com/vi/mkvparse/. An EBML = validator could work like this: >=20 > mkv2xml < test.mkv > output.xml > xmllint --noout --schema output.xml >=20 > I note that mkvalidator has some tests that are analogous to XML = validation against an XML Schema, but some are rules more similar to = Schematron. I=E2=80=99ll have to see if these rules could possibly to = stored properly in an XML Schema to verify if we=E2=80=99d need a second = schematron-like test. >=20 > Ideas? re: Updating mkvalidator to validate an EBML Dcoument validator = against an EBML Schema. Or. Using existing XML validation tools with an = EBML->XML conversion? This conversation continued in GitHub on the pull request here = https://github.com/Matroska-Org/ebml-specification/pull/40. Moritz = merged the PR though some issues remain for another one, such as = defining how to express EBML Element defaults when the default value may = be a string, integer, or reference to another Element=E2=80=99s value. The new merge adds a section on defining an EBML Schema, = https://github.com/Matroska-Org/ebml-specification/blob/master/specificati= on.markdown#ebml-schema. The current in-use EBML Schema is specdata.xml = which is here = https://github.com/Matroska-Org/foundation-source/blob/master/spectool/spe= cdata.xml. Now that we have a definition for specdata.xml, I suggest we = draft a new PR that updates the EBML Schema definition to bring it into = as much alignment with XML Schema=E2=80=99s specification as we can. = Alongside this i can update the XSL that converts the EBML Schema into = spec.xml which is used for documentation in the matroska.org website and = as a definition for use in mkvalidator. I think the EBML Specification is getting close to complete. There are = some open issues here, = https://github.com/Matroska-Org/ebml-specification/issues, some of which = relate to missing pieces of the spec and sections needed to bring the = spec moreso towards RFC style (adding a Security Consideration section). = Volunteers? Dave Rice From nobody Thu Dec 17 00:07:57 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573871B2AD8 for ; Thu, 17 Dec 2015 00:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, J_BACKHAIR_43=1] autolearn=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 XvHz6jDW7ju7 for ; Thu, 17 Dec 2015 00:07:54 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD4F1B2AD9 for ; Thu, 17 Dec 2015 00:07:54 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id a188so42420562vkc.0 for ; Thu, 17 Dec 2015 00:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5QaTUXtPCB0ZWQg6BgiwE6LQIi5mqI1vMYwfkA3xx8s=; b=ijPcxM5HyQ9jvua4FR8OXLgp15Ljso+sdH2F6YDl+GRyNO2ZklnbckqD3lpuL5OwsR j8tf/1tA4cRiARnhmzWFuATqaaPLsFIV9gGYrgpFQQRjWeE7p54ThfK4D73YPMqNuxka EcqkjLRkaMFqO0i09hZjU2KcA5H2jHTZ5p1ZTeYIrjpdTu9u1PcBusieOhmfodemgYdV JH5YaAzjL9Lnh4EHhDP3JUem2rjEo7Xh5WTM7zbsJqiq4YtGzUKupVw0o6aE3Uahh2uU Y6F+PNQmHTQny1ZKppEj8dqyCMTjdfm5g+ri8Eeq/vBdEj1OZliGba6WQw6jV7/4V3p+ eDfA== 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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5QaTUXtPCB0ZWQg6BgiwE6LQIi5mqI1vMYwfkA3xx8s=; b=ih6dPlT46IGLdcOxJeW5ZfJu70ZobpeSMtW24chjCibBjHz3tyXZfIWb/QN3LySJZP 4rb8hsyRAFrdKTVq7PBNfsrzx2Ah97pw4dToWwluUVjX0hrClfaAb48+B704fx0PxPLm 1fhcteCXqhS9v1BAsoPTAflKsTO7GW8/FXe1DtyVQ7aaklF+m2o+ihuUaRVm7Z6TIMxv 4ZWpP6lBUF+4L0P9Yfb6/YHwU5AzxxnfifmD+/hAub2x3GErpdONoaok4vjFBXzmwbrn 7NEy1685rGKf+EVjTgsX960MshHVPehnVKUOt0toIKCTi2TuzfRuXYDITruziszrKdFL pQLQ== X-Gm-Message-State: ALoCoQnyFDOb2zqFG1XdEVZd4bnd+jKPPFldLRqfYPyD69KduMKjwkX/UaWjoyLE7DVAUjrFmDFRwAd9pud+VOsJV1v4PUIfCg== MIME-Version: 1.0 X-Received: by 10.31.166.208 with SMTP id p199mr25690048vke.122.1450339673473; Thu, 17 Dec 2015 00:07:53 -0800 (PST) Received: by 10.31.8.84 with HTTP; Thu, 17 Dec 2015 00:07:53 -0800 (PST) In-Reply-To: <98E71C27-BF0D-4F8F-9E00-FFC69540C74C@dericed.com> References: <7B3D0399-D9DF-4800-A9B5-7CC6A3180232@dericed.com> <98E71C27-BF0D-4F8F-9E00-FFC69540C74C@dericed.com> Date: Thu, 17 Dec 2015 09:07:53 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Discussion about the current and future development of Matroska , Michael Bradshaw , cellar@ietf.org Subject: Re: [Cellar] Defining EBML Schema in the EBML spec & mandatory/default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2015 08:07:57 -0000 2015-12-08 14:17 GMT+01:00 Dave Rice : > >> On Dec 8, 2015, at 4:20 AM, Steve Lhomme wrote: >> >> 2015-12-07 19:04 GMT+01:00 Dave Rice : >>> >>> On Dec 7, 2015, at 12:37 PM, Michael Bradshaw wrot= e: > > [=E2=80=A6] > >>> One caution I have here is that the current specdata.xml file is used t= o >>> create libraries that are used to build mkvalidator. I think possibly a >>> different specdata.xml could be used to create a validator from mkvalid= ator >>> code for another EBML format. However, mkvalidator likely does not supp= ort >>> much outside of the current `range` values. If we use something broader= like >>> XML Schema's restriction we could end up making EBML Schemas that can n= ot be >>> used within mkvalidator. On the other hand, support for string restrict= ions >>> would allow us to have a machine-readable test on Matroska tags, wherea= s we >>> >>> If we standardize EBML Schema, I think it's practically essential to ha= ve a >>> utility that can use the EBML Schema to validate an EBML Document. To d= o >>> that there is mkvalidator and inside the PreForma project there is work >>> underway to build an EBML validator using a combination of MediaTrace a= nd >>> XSL. >> >> If we go the XSLT way, I suppose a more flexible validator could be >> written using that and be easily updated on the fly, compared to a >> compile program like mkvalidator. >> >>> Cc'ing matroska-devel on this, but I like to ask: >>> If EBML Schema is extended to support more comprehensive expressions th= at >>> specdata.xml currently supports, are there volunteers to update mkvalid= ator >>> to support the new EBML Schema? I can volunteer to update data2spec to >>> produce a similar output but feasibly our work on EBML Schema may mean = that >>> it then continues unpredicted expressions. >> >> I will continue maintaining mkvalidator, until another validator >> supports all the same error/warning detections and profiles (live, >> webm, divx). > > Thanks Steve. > > I realize that another approach we could use is to convert EBML to XML an= d then validate the resulting XML with an XML Schema that defines an EBML f= ormat. This would means that we could use any XML validator instead of nece= ssarily needing a custom EBML validator. There is already an EBML<->XML con= verter here https://github.com/vi/mkvparse/. An EBML validator could work l= ike this: > > mkv2xml < test.mkv > output.xml > xmllint --noout --schema output.xml > > I note that mkvalidator has some tests that are analogous to XML validati= on against an XML Schema, but some are rules more similar to Schematron. I= =E2=80=99ll have to see if these rules could possibly to stored properly in= an XML Schema to verify if we=E2=80=99d need a second schematron-like test= . I think there can be more than one validator. One using XML is certainly useful. On the other hand, given the tight binary nature of EBML, it may produce very large files. But it will probably be limited to basic EBML. For example for Matroska it would be tricky to verify Cues refer to proper Clusters/frames without being able to seek in the XML file or keep everything in memory. The C based validator is being "smart" about this and keeps things in memory depending on the mode it's being used. It also uses the tight in-memory representation of an EBML element. Whereas an XML parser will likely use a lot more memory for each possible named element. > Ideas? re: Updating mkvalidator to validate an EBML Dcoument validator ag= ainst an EBML Schema. Or. Using existing XML validation tools with an EBML-= >XML conversion? That would be a nice goal. But as described above, some further checks may not be possible with such an approach. --=20 Steve Lhomme Matroska association Chairman From nithinmkurien@gmail.com Thu Dec 17 02:41:34 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D131A8A8F for ; Thu, 17 Dec 2015 02:41:34 -0800 (PST) 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=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 OHJP_4IoYNDE for ; Thu, 17 Dec 2015 02:41:33 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 E0F4C1A8A4D for ; Thu, 17 Dec 2015 02:41:32 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id x184so13701064yka.3 for ; Thu, 17 Dec 2015 02:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3GrbQvwa+NGkMcsE6/ltyonSTSszSx8QkD/ylEj/zZM=; b=TREYiVyQDFGntERMaw+872D6iUVlCzZ+Y9O1aQBsNpVBRQ4Aq6tZYnq8bpGB1did9z NrORaTmBfPeJ+gaoh/hT/e+Z0YDdjPLLB+664UQToq7YEMp6/KZpXfn3g1SAmt7UzZf8 d8JM5Q0uADELoZcI2elRcUcL/AB/7IgVNXDth9YlmPngt08oEOhGY5eagWFTMuhJi8p/ ysRLCsl/XYQp32tI8NWGcz7vPtKX6Z/IHOwLvDhfC1zE+UBOTFe3493yRgRqjSo5dn33 9oNptRyfrPMzAQJI7ZnCnbh87l4/Qv26nTydRVR9KcTzJFwhytWY5ztbOuA442ft92jo u9Vg== MIME-Version: 1.0 X-Received: by 10.13.240.66 with SMTP id z63mr28959237ywe.171.1450348892141; Thu, 17 Dec 2015 02:41:32 -0800 (PST) Received: by 10.129.113.6 with HTTP; Thu, 17 Dec 2015 02:41:32 -0800 (PST) Date: Thu, 17 Dec 2015 16:11:32 +0530 Message-ID: From: Nithin Mathew Kurien To: cellar@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Cellar] Menu System in Matroska Files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2015 10:43:16 -0000 Dear all, The Matroska specification includes a menu system which is currently in a draft state (http://matroska.org/technical/menu/index.html). Currently there are no open-source players supporting this feature. But there is at least one proprietary format, namely PGMX, a variant of MKV, that includes a working menu. These files are created by a proprietary TMPGENC PGMX creator and played by a freeware TMPGENC PGMX player. A PGMX file also supports including multiple related titles inside a single file. Opening this file on open-source players will play it as a normal MKV file without menus. There are some samples given in their website (http://tmpgenc.pegasys-inc.com/en/download/tpxp.html). I think the menu feature would be a good idea to implement in Matroska files and humbly request for the same. I think this feature would be useful for content authors who would like to distribute their works freely under a Creative Commons license, for example, who would otherwise have to adopt proprietary formats like DVD and Blu-ray. I understand that implementing a menu system from scratch might involve some complexity. In that case, would it be possible to adopt some features from the open-source libdvdnav and libbluray? Thanks and regards, Nithin From nobody Fri Dec 18 07:17:45 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6881B3674 for ; Fri, 18 Dec 2015 07:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 qRtOmZZZ3ufZ for ; Fri, 18 Dec 2015 07:17:41 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82E71B342B for ; Fri, 18 Dec 2015 07:17:41 -0800 (PST) Received: from [146.96.19.240] (port=26332 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1a9wmq-000MSH-5C; Fri, 18 Dec 2015 10:17:41 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_D3946AC7-B581-4E08-A56F-855F0F5A6A44" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Dave Rice In-Reply-To: Date: Fri, 18 Dec 2015 10:17:38 -0500 Message-Id: References: To: Nithin Mathew Kurien X-Mailer: Apple Mail (2.1990.1) X-OutGoing-Spam-Status: No, score=-1.0 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-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Menu System in Matroska Files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2015 15:17:44 -0000 --Apple-Mail=_D3946AC7-B581-4E08-A56F-855F0F5A6A44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On Dec 17, 2015, at 5:41 AM, Nithin Mathew Kurien = wrote: >=20 > Dear all, >=20 > The Matroska specification includes a menu system which is currently > in a draft state (http://matroska.org/technical/menu/index.html). This draft document seems to list features and requirements but does not = clarify how to read or write such menu data. AFAIK this is still only an = early draft, but could possibly be worked on in coordination of = standardizing Matroska version 4. > Currently there are no open-source players supporting this feature. > But there is at least one proprietary format, namely PGMX, a variant > of MKV, that includes a working menu. I'm glad to see this sample as it demonstrates a lot of edge cases in = earlier discussion on EBML structure. The sample, = http://download1.pegasys-inc.com/download_files/TPXC_materials/elephants_d= ream.pgmx = , contains 3 EBML Headers, each followed by its own Segment = Element. Within the current state of the EBML specification work, this = file would be considered an EBML Stream that contains three EBML = Documents. The last EBML Document contains 32 attachments, including = Navigation.xml, which I extracted to = https://gist.github.com/dericed/13ac0fab10a1bed54e37 = , and lots of png = files. It also contains Matroska attachments within Matroska :). It also seems that most Matroska demuxers ignore the non-first Segment = elements. I'm not familiar enough with navigation to comment much but I suspect = that adding a menu to a Matroska file should not require the creation of = additional EBML Documents within an EBML Stream. The existing system to = reference to link between chapters, tracks, and time currently only = coordinations relationships within the same EBML Document. > These files are created by a > proprietary TMPGENC PGMX creator and played by a freeware TMPGENC PGMX > player. A PGMX file also supports including multiple related titles > inside a single file. Opening this file on open-source players will > play it as a normal MKV file without menus. There are some samples > given in their website > (http://tmpgenc.pegasys-inc.com/en/download/tpxp.html). >=20 > I think the menu feature would be a good idea to implement in Matroska > files and humbly request for the same. I think this feature would be > useful for content authors who would like to distribute their works > freely under a Creative Commons license, for example, who would > otherwise have to adopt proprietary formats like DVD and Blu-ray. I agree that an open format media file with menu based navigation is = important. I'd suggest that it could be considered as part of the CELLAR = timeline to work on Matroska version 4. > I > understand that implementing a menu system from scratch might involve > some complexity. In that case, would it be possible to adopt some > features from the open-source libdvdnav and libbluray? I'm not familiar enough with these two to comment but integrating an = existing menu specification with a compatible license may work. You = could also review matroska-devel to see how earlier menu discussions = progressed. Dave > Thanks and regards, > Nithin >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_D3946AC7-B581-4E08-A56F-855F0F5A6A44 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On Dec 17, 2015, at 5:41 AM, = Nithin Mathew Kurien <nithinmkurien@gmail.com> wrote:

Dear all,

The Matroska specification includes a menu = system which is currently
in a draft state (http://matroska.org/technical/menu/index.html).

This draft = document seems to list features and requirements but does not clarify = how to read or write such menu data. AFAIK this is still only an early = draft, but could possibly be worked on in coordination of standardizing = Matroska version 4.

Currently there are no open-source players = supporting this feature.
But there is at least one = proprietary format, namely PGMX, a variant
of MKV, that = includes a working menu.

I'm glad to see this sample as it demonstrates a = lot of edge cases in earlier discussion on EBML structure. The = sample, http://download1.pegasys-inc.com/download_files/TPXC_materials/= elephants_dream.pgmx, contains 3 EBML Headers, each followed by its = own Segment Element. Within the current state of the EBML specification = work, this file would be considered an EBML Stream that contains three = EBML Documents. The last EBML Document contains 32 attachments, = including Navigation.xml, which I extracted to https://gist.github.com/dericed/13ac0fab10a1bed54e37, and = lots of png files. It also contains Matroska attachments within Matroska = :).

It also seems that most Matroska = demuxers ignore the non-first Segment elements.

I'm not familiar enough with navigation to comment = much but I suspect that adding a menu to a Matroska file should not = require the creation of additional EBML Documents within an EBML Stream. = The existing system to reference to link between chapters, tracks, and = time currently only coordinations relationships within the same EBML = Document.

These files are created by a
proprietary = TMPGENC PGMX creator and played by a freeware TMPGENC PGMX
player. A PGMX file also supports including multiple related = titles
inside a single file. Opening this file on = open-source players will
play it as a normal MKV file = without menus. There are some samples
given in their = website
(http://tmpgenc.pegasys-inc.com/en/download/tpxp.html).

I think the menu feature would be a good idea = to implement in Matroska
files and humbly request for the = same. I think this feature would be
useful for content = authors who would like to distribute their works
freely = under a Creative Commons license, for example, who would
otherwise have to adopt proprietary formats like DVD and = Blu-ray.

I agree that = an open format media file with menu based navigation is important. I'd = suggest that it could be considered as part of the CELLAR timeline to = work on Matroska version 4.

I
understand that = implementing a menu system from scratch might involve
some = complexity. In that case, would it be possible to adopt some
features from the open-source libdvdnav and libbluray?

I'm not = familiar enough with these two to comment but integrating an existing = menu specification with a compatible license may work. You could also = review matroska-devel to see how earlier menu discussions = progressed.
Dave

Thanks and regards,
Nithin

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

= --Apple-Mail=_D3946AC7-B581-4E08-A56F-855F0F5A6A44-- From nobody Fri Dec 18 10:56:25 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9A31B382D for ; Fri, 18 Dec 2015 10:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 058M-3Du3TUR for ; Fri, 18 Dec 2015 10:56:22 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 D97A11B382C for ; Fri, 18 Dec 2015 10:56:21 -0800 (PST) Received: from [192.168.2.129] ([188.100.175.162]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MWCgz-1ZhdYQ1OTR-00XMm3 for ; Fri, 18 Dec 2015 19:56:19 +0100 To: cellar@ietf.org References: From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE X-Enigmail-Draft-Status: N1110 Message-ID: <567456CF.7090008@gmx.de> Date: Fri, 18 Dec 2015 19:56:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.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:4Xcr8dnFSsbGGHXUxEZQ0QAU/AdU6iLeZ4bXCzhFVcyAIpOMRC/ eQeVezOe4/06YzbZXATpi/iETp0Prss6gIDXcp3kssogomOal57vRl9NNSnWRtpdI7dEnKn vBj29S/oGxT+RjEm26yEYu5lvpLODf5zu07TsiuCJlScUun1/44S6PnRfQ17Z7jV147JRsX KgyTYMjiAYmeDDS50l5fA== X-UI-Out-Filterresults: notjunk:1;V01:K0:fEC8TEk0M1k=:hZzDmVeo0WiY/vSOgolsBa WrTyMxM6m42HVAgLduIVe8QfBCY07M5QxeNswXs1i6W2DdsLbYLFxqeerwm7wrJWG3HkOpdWf vswQktH1Im4vAD1nQJnSzJZnI4+35ttbyI02un6jM0doTBGlM5nbl4fKR8ugk7XUex3X2MWxh dWPDex/zQFdkv7X6XwFHremhZNBNqhQdDYX/9G6spqXbJLdTkvGc3MJNGoGjPixXumoefugHK +H/vAlNk0YwSWpDwgvz7PCvUleR4vojFnV0MT1CJrFsQVcDlR4UYvdQZ6gNmX0+FykeSDSBgL UUdxsG9O1+nha9P5/ELqJl3x0OXZmxTPz/voGDzcKiKQ8T/aHRHPlqv0lbbg1KfSrgKxpTiMc keIwrzt4+uJE6JIfChjGuM+rEMR2b6AlG+x6y9j4tdn+19pfHUtPNHSCR1JeBIpzm+JDgTDLC 0ybgvA4IlMcg3H/vxKq1AcTzNeEogSDLXCWYphm7Nmi3Y7SxQLidtK9SYDhj3T35BtnOf4Eou taHLsEwz3/70OK1zG1X9GRQduyebecbPpGwnRjgCARVbezwfsKVc8/UDzGV37RH9uvL+tkhpo JTc+3IO5ee/WNprFWzu7dOA+fAdl5v4knPBJ0Y6wsm7Qj+xj6onwCycn00bC4L/IrIZ6OwkWE PBJ/iKVCm5D96HpWHYchQq7rX8bfAPx9yS9HdCsFyj1EY/I/dqxo+aIu77xXYZW7Q57s1xPC5 TCcokxyKneLZoi8mj5vB+qZVjs/56Pdj62RMqljPCSUzKJN17AZuYH2z+gh9l2G3ELVcLfaI4 3gV5KQA Archived-At: Subject: Re: [Cellar] Menu System in Matroska Files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2015 18:56:23 -0000 18.12.2015, 16:17 Dave Rice: > The existing system to reference to link between chapters, tracks, > and time currently only coordinations relationships within the same > EBML Document. I cut out the rest, but kept the sentence intact. The reason I single out this sentence is because I don't understand it. I am unable to understand its meaning. It appears like 'to link' and 'to reference' where meant to substitute each other. "The existing system ... are currently only coordination relationships within the same EBML document." ? "The existing system ... is currently only coordinating relationships (between elements) within the same EBML document."? Or something different? Thank you in advance. Best Regards, Sebastian p.s.: I will not reply to this thread if I get a satisfying answer and have nothing to contribute to in order to make less noise in the inboxes of subscribers. p.p.s.: Menus might add a lot of complexity, but they are surly useful. From nobody Fri Dec 18 11:33:17 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30441B3860 for ; Fri, 18 Dec 2015 11:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 RhHnXaeyYxHW for ; Fri, 18 Dec 2015 11:33:15 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 DF43F1B2F24 for ; Fri, 18 Dec 2015 11:33:14 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id x184so70070518yka.3 for ; Fri, 18 Dec 2015 11:33:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GrkO2geJwTVtzICDQled+Is0ugWtQ7O2DtZijHOpdTw=; b=cFEccXdlr7XDQeHW5czQTJjP++GcNByc3ocltr2ePlRO+/2udQW2AVx6w60VyGoLR+ HE9RCyYtQhPM4p9+HrM8IjLC7iEvGCYfzB/NGSwWf6uy1YQSgMeJsD/tBVPfNPyBPRoC C7CWF9lWsXr+V4TBHlAUIzug6LTmoJUBBJ/cvXmSf/bVTJFjutFF+og9IDonT4tOHlxv I6A3laBXhDAZ510AjUS8j6GDCE7kk9TPcxNljQbEtzj1ofLKYcg2O1VCWSMB5GBD1YCx Ww7jUuesV8xFlOUs7cRXngFNri6aF1kuIcNQcXhzzapI66ha8yT0BO1zIupaUFZkBRrI DHvQ== MIME-Version: 1.0 X-Received: by 10.13.192.130 with SMTP id b124mr4989410ywd.218.1450467194069; Fri, 18 Dec 2015 11:33:14 -0800 (PST) Received: by 10.129.113.6 with HTTP; Fri, 18 Dec 2015 11:33:13 -0800 (PST) In-Reply-To: References: Date: Sat, 19 Dec 2015 01:03:13 +0530 Message-ID: From: Nithin Mathew Kurien To: Dave Rice Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Discussion about the current and future development of Matroska , cellar@ietf.org Subject: Re: [Cellar] Menu System in Matroska Files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2015 19:33:17 -0000 Hi, On Fri, Dec 18, 2015 at 8:47 PM, Dave Rice wrote: > Hi, > > On Dec 17, 2015, at 5:41 AM, Nithin Mathew Kurien > wrote: > > Dear all, > > The Matroska specification includes a menu system which is currently > in a draft state (http://matroska.org/technical/menu/index.html). > > > This draft document seems to list features and requirements but does not > clarify how to read or write such menu data. AFAIK this is still only an > early draft, but could possibly be worked on in coordination of > standardizing Matroska version 4. > > Currently there are no open-source players supporting this feature. > But there is at least one proprietary format, namely PGMX, a variant > of MKV, that includes a working menu. > > > I'm glad to see this sample as it demonstrates a lot of edge cases in > earlier discussion on EBML structure. The sample, > http://download1.pegasys-inc.com/download_files/TPXC_materials/elephants_dream.pgmx, > contains 3 EBML Headers, each followed by its own Segment Element. Within > the current state of the EBML specification work, this file would be > considered an EBML Stream that contains three EBML Documents. The last EBML > Document contains 32 attachments, including Navigation.xml, which I > extracted to https://gist.github.com/dericed/13ac0fab10a1bed54e37, and lots > of png files. It also contains Matroska attachments within Matroska :). > > It also seems that most Matroska demuxers ignore the non-first Segment > elements. > > I'm not familiar enough with navigation to comment much but I suspect that > adding a menu to a Matroska file should not require the creation of > additional EBML Documents within an EBML Stream. The existing system to > reference to link between chapters, tracks, and time currently only > coordinations relationships within the same EBML Document. > > These files are created by a > proprietary TMPGENC PGMX creator and played by a freeware TMPGENC PGMX > player. A PGMX file also supports including multiple related titles > inside a single file. Opening this file on open-source players will > play it as a normal MKV file without menus. There are some samples > given in their website > (http://tmpgenc.pegasys-inc.com/en/download/tpxp.html). > > I think the menu feature would be a good idea to implement in Matroska > files and humbly request for the same. I think this feature would be > useful for content authors who would like to distribute their works > freely under a Creative Commons license, for example, who would > otherwise have to adopt proprietary formats like DVD and Blu-ray. > > > I agree that an open format media file with menu based navigation is > important. I'd suggest that it could be considered as part of the CELLAR > timeline to work on Matroska version 4. > > I > understand that implementing a menu system from scratch might involve > some complexity. In that case, would it be possible to adopt some > features from the open-source libdvdnav and libbluray? > > > I'm not familiar enough with these two to comment but integrating an > existing menu specification with a compatible license may work. You could > also review matroska-devel to see how earlier menu discussions progressed. Thanks. I am cc'ing the e-mail to matroska-devel also. > Dave > > Thanks and regards, > Nithin > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > Thanks and regards, Nithin From nobody Fri Dec 18 12:03:51 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7171A8902 for ; Fri, 18 Dec 2015 12:03:49 -0800 (PST) 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_20=-0.001, SPF_NEUTRAL=0.779] autolearn=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 FfyF8iO8cEUa for ; Fri, 18 Dec 2015 12:03:48 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600311B3896 for ; Fri, 18 Dec 2015 12:03:48 -0800 (PST) Received: from [146.96.19.240] (port=25235 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1aA1Fj-0039AE-BH for cellar@ietf.org; Fri, 18 Dec 2015 15:03:47 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Dave Rice In-Reply-To: <567456CF.7090008@gmx.de> Date: Fri, 18 Dec 2015 15:03:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7524AC07-3243-45D0-9289-9525B9A2DD83@dericed.com> References: <567456CF.7090008@gmx.de> To: cellar@ietf.org X-Mailer: Apple Mail (2.1990.1) X-OutGoing-Spam-Status: No, score=-1.0 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-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Menu System in Matroska Files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2015 20:03:50 -0000 Hi, > On Dec 18, 2015, at 1:56 PM, Sebastian G. wrote: >=20 > 18.12.2015, 16:17 Dave Rice: >> The existing system to reference to link between chapters, tracks, >> and time currently only coordinations relationships within the same >> EBML Document. >=20 > I cut out the rest, but kept the sentence intact. >=20 > The reason I single out this sentence is because I don't understand = it. > I am unable to understand its meaning. It appears like 'to link' and = 'to > reference' where meant to substitute each other. >=20 > "The existing system ... are currently only coordination relationships > within the same EBML document." ? >=20 > "The existing system ... is currently only coordinating relationships > (between elements) within the same EBML document."? >=20 > Or something different? I obviously wrote far too quickly, thanks for requesting clarification. = I think I had meant to say: "The existing system to reference in-between = chapters, tracks, and time currently only coordinates relationships = within the same EBML Document. However in studying the current Matroska specification again, I see = that I may not be correct. I was considering Matroska Elements such as 'Targets'. Here the current = definition says: "Contain all UIDs where the specified meta data apply. = It is empty to describe everything in the segment." I had presumed that = the Target could only reference a UID within the same Segment element, = but I don't think the definition is written in a way that prevents that. The cited example file contains a structure like: ... ... ... ... ... ... And contains UID references within the third Segment that reference the = first Segment and tracks within it. > Thank you in advance. >=20 > Best Regards, > Sebastian >=20 > p.s.: I will not reply to this thread if I get a satisfying answer and > have nothing to contribute to in order to make less noise in the = inboxes > of subscribers. >=20 > p.p.s.: Menus might add a lot of complexity, but they are surly = useful. Agreed. Dave Rice From nobody Sun Dec 27 12:03:11 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4461A1F70 for ; Sun, 27 Dec 2015 12:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 jAj7inuDwWMS for ; Sun, 27 Dec 2015 12:03:08 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::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 09BD51A1F20 for ; Sun, 27 Dec 2015 12:03:07 -0800 (PST) Received: by mail-lb0-x236.google.com with SMTP id sv6so77195261lbb.0 for ; Sun, 27 Dec 2015 12:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ClbLpFmdiyYLtjWjDj5cc5hqFqlFWSpc5d0TXxj3TNw=; b=ccxa7nfMMOUgtVcwSm8hOCmHt5lgzBRAqxI8kcxg3QuLRTL1pM4oN6eF/cVxYk1urc OkOahhJHwQAepUQ3GGwrxhf8/z5LfeFCiuiBx2uBh0IBybjQTs7yoOwcInCJ1SKzRnOS J+9uC/ZlCTRroHZ45BsfngA/V5k5M38opQ7Vd/JB1WmM51kPPtWj8W5ckjv57oWCDOgD FDCYJDnHpcd+Q8pE6kIwtBhbp36STzkRWnecTb1/wEPFYY6BJUiwLCo8z5cGtJ67Uf0k q6WwHET/HubFfROysESzAdm2B/r2vyPir+8URtktJMBbQ8jLR+T6r7Vx4Zmw6IE2DQYG UioA== MIME-Version: 1.0 X-Received: by 10.112.139.38 with SMTP id qv6mr17652290lbb.36.1451246586080; Sun, 27 Dec 2015 12:03:06 -0800 (PST) Received: by 10.25.78.206 with HTTP; Sun, 27 Dec 2015 12:03:06 -0800 (PST) Date: Sun, 27 Dec 2015 20:03:06 +0000 Message-ID: From: Kieran O Leary To: cellar@ietf.org Content-Type: multipart/alternative; boundary=089e01182a7e3eb8630527e6ad7a Archived-At: Subject: [Cellar] Data stream support in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 27 Dec 2015 20:03:10 -0000 --089e01182a7e3eb8630527e6ad7a Content-Type: text/plain; charset=UTF-8 Hello, Matroska does not currently support data tracks. From my experience working in a moving image archive, a lot of quicktime files from Final Cut Pro can end up with a timecode data track. I can't remember off the top of my head if AVID MC does this as well. The timecode always seems to exist as metadata in the actual AV streams so the information isn't lost when the data track doesn't exist. It would be nice if matroska supported it, though. It would be preferable to maintain all streams within the original file when migrating to the matroska container. If I'm converting a v210 quicktime with multiple audio tracks to ffv1.mkv with ffmpeg, I end up using `-map 0 -dn` (`-map 0:a -map 0:v` would also work, but an extra condition would have to be scripted if some embedded subtitles existed in some files). Best regards, Kieran O'Leary IFI Irish Film Archive --089e01182a7e3eb8630527e6ad7a Content-Type: text/html; charset=UTF-8
Hello,

Matroska does not currently support data tracks. From my experience working in a moving image archive, a lot of quicktime files from Final Cut Pro can end up with a timecode data track. I can't remember off the top of my head if AVID MC does this as well.

The timecode always seems to exist as metadata in the actual AV streams so the information isn't lost when the data track doesn't exist. It would be nice if matroska supported it, though. It would be preferable to maintain all streams within the original file when migrating to the matroska container.

If I'm converting a v210 quicktime with multiple audio tracks to ffv1.mkv with ffmpeg, I end up using `-map 0 -dn` (`-map 0:a -map 0:v` would also work, but an extra condition would have to be scripted if some embedded subtitles existed in some files).


Best regards,

Kieran O'Leary
IFI Irish Film Archive
--089e01182a7e3eb8630527e6ad7a-- From nobody Sun Dec 27 12:17:20 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF29A1A21B3 for ; Sun, 27 Dec 2015 12:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 tGcVNakfu1On for ; Sun, 27 Dec 2015 12:17:16 -0800 (PST) Received: from 20.mo1.mail-out.ovh.net (20.mo1.mail-out.ovh.net [188.165.45.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A24F1A21B5 for ; Sun, 27 Dec 2015 12:17:16 -0800 (PST) Received: from mail183.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo1.mail-out.ovh.net (Postfix) with SMTP id 71740FFB427 for ; Sun, 27 Dec 2015 21:17:14 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 27 Dec 2015 22:17:13 +0200 Received: from p4fe1ee8b.dip0.t-ipconnect.de (HELO ?192.168.2.103?) (zen@mediaarea.net@79.225.238.139) by ns0.ovh.net with SMTP; 27 Dec 2015 22:17:11 +0200 To: cellar@ietf.org References: From: Jerome Martinez Message-ID: <56804743.9050209@mediaarea.net> Date: Sun, 27 Dec 2015 21:17:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030908010009040709010906" X-Ovh-Tracer-Id: 5136073900305354898 X-Ovh-Remote: 79.225.238.139 (p4fe1ee8b.dip0.t-ipconnect.de) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedrheefucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedrheehgddufeduucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Data stream support in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 27 Dec 2015 20:17:19 -0000 This is a multi-part message in MIME format. --------------030908010009040709010906 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 27/12/2015 21:03, Kieran O Leary wrote: > Hello, > > Matroska does not currently support data tracks. From my experience > working in a moving image archive, a lot of quicktime files from Final > Cut Pro can end up with a timecode data track. I can't remember off > the top of my head if AVID MC does this as well. > > The timecode always seems to exist as metadata in the actual AV > streams so the information isn't lost when the data track doesn't exist. I wonder how you see the time code in your transcoded Matroska file, I see not place for it (and v210 raw stream can not contain any time code) As far as I know, the time code information is lost during QuickTime to Matroska remuxing. > It would be nice if matroska supported it, though. It would be > preferable to maintain all streams within the original file when > migrating to the matroska container. "All" is always difficult to do, because containers do not have the same capabilities (especially tags). And QuickTime time codes are very specific (very tied to QuickTime container format). But I agree that having ancillary data (time code or any other ancillary stream) in Matroska may be useful for handling more cases. > > If I'm converting a v210 quicktime with multiple audio tracks to > ffv1.mkv with ffmpeg, I end up using `-map 0 -dn` (`-map 0:a -map 0:v` > would also work, but an extra condition would have to be scripted if > some embedded subtitles existed in some files). > > > Best regards, > > Kieran O'Leary > IFI Irish Film Archive > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --------------030908010009040709010906 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 27/12/2015 21:03, Kieran O Leary wrote:
Hello,

Matroska does not currently support data tracks. From my experience working in a moving image archive, a lot of quicktime files from Final Cut Pro can end up with a timecode data track. I can't remember off the top of my head if AVID MC does this as well.

The timecode always seems to exist as metadata in the actual AV streams so the information isn't lost when the data track doesn't exist.

I wonder how you see the time code in your transcoded Matroska file, I see not place for it (and v210 raw stream can not contain any time code)
As far as I know, the time code information is lost during QuickTime to Matroska remuxing.

It would be nice if matroska supported it, though. It would be preferable to maintain all streams within the original file when migrating to the matroska container.

"All" is always difficult to do, because containers do not have the same capabilities (especially tags).
And QuickTime time codes are very specific (very tied to QuickTime container format).
But I agree that having ancillary data (time code or any other ancillary stream) in Matroska may be useful for handling more cases.


If I'm converting a v210 quicktime with multiple audio tracks to ffv1.mkv with ffmpeg, I end up using `-map 0 -dn` (`-map 0:a -map 0:v` would also work, but an extra condition would have to be scripted if some embedded subtitles existed in some files).


Best regards,

Kieran O'Leary
IFI Irish Film Archive


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

--------------030908010009040709010906-- From nobody Sun Dec 27 12:43:40 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BBC1A6EE4 for ; Sun, 27 Dec 2015 12:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=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 0VFQORxNPBO3 for ; Sun, 27 Dec 2015 12:43:35 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 1EE8E1A6EE1 for ; Sun, 27 Dec 2015 12:43:35 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id p203so192279632lfa.0 for ; Sun, 27 Dec 2015 12:43:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=EWSKA4g+HAOGaLqQGLcjzPJno/ITGUiZFEe9Pvle9a4=; b=Xd7dskzRP8R/6nXFMDGbSMKpNDk80gsOanYHlbwsSXT7Nr/wP8p0oobfbjtqRaxQeK WcFxWptmpBz5Rw4k0cBFaZPPofNjqHQImFrbx1o5eZly1ws1xz62COSa0n1mvWsd1pi9 NRHjxSyXcIGrQgNhKfXgBgpTByGc2OOtG8pcVGcIT3xIKWDE9XMPigAfsVRcz5HEC6Uu zkCNzIWFmR/zlxS57jfsGmg/+dxX1Zy5xqSkihfE0tlvVEvB0otyLwsyxIbFpv0o4sSx A1b0dZ8Xt6kPRkHhGXOl185p6KwRHYGvNuu+wcIvAdRjWMF0xOYJALedg3GetlpbSGyu s8Kg== MIME-Version: 1.0 X-Received: by 10.25.28.70 with SMTP id c67mr15063882lfc.95.1451249013241; Sun, 27 Dec 2015 12:43:33 -0800 (PST) Received: by 10.25.78.206 with HTTP; Sun, 27 Dec 2015 12:43:33 -0800 (PST) In-Reply-To: <56804743.9050209@mediaarea.net> References: <56804743.9050209@mediaarea.net> Date: Sun, 27 Dec 2015 20:43:33 +0000 Message-ID: From: Kieran O Leary To: Jerome Martinez , cellar@ietf.org Content-Type: multipart/alternative; boundary=001a11402258ea3f920527e73d71 Archived-At: Subject: Re: [Cellar] Data stream support in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 27 Dec 2015 20:43:39 -0000 --001a11402258ea3f920527e73d71 Content-Type: text/plain; charset=UTF-8 On Sun, Dec 27, 2015 at 8:17 PM, Jerome Martinez wrote: > > On 27/12/2015 21:03, Kieran O Leary wrote: > > Hello, > > Matroska does not currently support data tracks. From my experience > working in a moving image archive, a lot of quicktime files from Final Cut > Pro can end up with a timecode data track. I can't remember off the top of > my head if AVID MC does this as well. > > The timecode always seems to exist as metadata in the actual AV streams so > the information isn't lost when the data track doesn't exist. > > > I wonder how you see the time code in your transcoded Matroska file, I see > not place for it (and v210 raw stream can not contain any time code) > As far as I know, the time code information is lost during QuickTime to > Matroska remuxing. > Hi Jerome, Thanks for getting back so quick. The only test files I have to hand are here: https://archive.org/details/test20100622_v210_and_ffv1 The v210.mov from that link has a timecode track (will post full ffmpeg output of both files at the bottom of the email just to be safe): Stream #0:6(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default) Metadata: creation_time : 2010-05-25 22:47:06 handler_name : Apple Alias Data Handler reel_name : DHC0034_1984.0040_pmaster timecode : 00:30:40:13 This timecode info also appears in the video stream: Stream #0:0(eng): Video: v210 (v210 / 0x30313276), yuv422p10le(bt470bg/smpte240m/unknown), 720x486, 222820 kb/s, 29.85 fps, 29.97 tbr, 2997 tbn, 2997 tbc (default) Metadata: creation_time : 2010-05-25 22:47:06 handler_name : Apple Alias Data Handler encoder : Uncompressed 10 bit timecode : 00:30:40:13 Stream #0:1(eng): Subtitle: eia_608 (c608 / 0x38303663), 640x480, 4 kb/s (default) I transcoded the file to ffv1.mkv and the timecode info is preserved as part of the video stream: Stream #0:4(eng): Video: ffv1 (FFV1 / 0x31564646), yuv422p10le, 720x486, SAR 1:1 DAR 40:27, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default) Metadata: CREATION_TIME : 2010-05-25 22:47:06 LANGUAGE : eng HANDLER_NAME : Apple Alias Data Handler TIMECODE : 00:30:40:13 ENCODER : Lavc56.60.100 ffv1 DURATION : 00:00:01.001000000 My command line was ffmpeg -i '/home/kieranjol/Downloads/DHC36.v210.pcm.mov' -c:v ffv1 -level 3 -g 1 -t 1 -c:a copy -map 0:a -map 0:v '/home/kieranjol/Downloads/DHC36.v210.pcm.mkv' Here's the ffmpeg -i from the v210 original, and the ffv1.mkv will follow. ffmpeg -i '/home/kieranjol/Downloads/DHC36.v210.pcm.mov' ffmpeg version 2.8.1 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04) configuration: --prefix=/home/kieranjol/.linuxbrew/Cellar/ffmpeg/2.8.1 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=/usr/bin/gcc-4.8 --host-cflags='-Os -w -pipe -march=core2' --host-ldflags='-L/home/kieranjol/.linuxbrew/lib -Wl,-rpath,/home/kieranjol/.linuxbrew/lib' --enable-libx264 --enable-libmp3lame --enable-libvo-aacenc --enable-libxvid --enable-libfreetype --enable-ffplay --enable-vda libavutil 54. 31.100 / 54. 31.100 libavcodec 56. 60.100 / 56. 60.100 libavformat 56. 40.101 / 56. 40.101 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 40.101 / 5. 40.101 libavresample 2. 1. 0 / 2. 1. 0 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.101 / 1. 2.101 libpostproc 53. 3.100 / 53. 3.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/home/kieranjol/Downloads/DHC36.v210.pcm.mov': Metadata: creation_time : 2010-05-25 22:46:56 timecode : 00:30:40:13 Duration: 00:00:09.91, start: 0.040375, bitrate: 230674 kb/s Stream #0:0(eng): Video: v210 (v210 / 0x30313276), yuv422p10le(bt470bg/smpte240m/unknown), 720x486, 222820 kb/s, 29.85 fps, 29.97 tbr, 2997 tbn, 2997 tbc (default) Metadata: creation_time : 2010-05-25 22:47:06 handler_name : Apple Alias Data Handler encoder : Uncompressed 10 bit timecode : 00:30:40:13 Stream #0:1(eng): Subtitle: eia_608 (c608 / 0x38303663), 640x480, 4 kb/s (default) Metadata: creation_time : 2010-05-25 22:47:06 handler_name : Apple Alias Data Handler Stream #0:2(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32 (24 bit), 1152 kb/s (default) Metadata: creation_time : 2010-05-25 22:47:06 handler_name : Apple Alias Data Handler Stream #0:3(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32 (24 bit), 1152 kb/s (default) Metadata: creation_time : 2010-05-25 22:47:06 handler_name : Apple Alias Data Handler Stream #0:4(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32 (24 bit), 1152 kb/s (default) Metadata: creation_time : 2010-05-25 22:47:06 handler_name : Apple Alias Data Handler Stream #0:5(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32 (24 bit), 1152 kb/s (default) Metadata: creation_time : 2010-05-25 22:47:06 handler_name : Apple Alias Data Handler Stream #0:6(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default) Metadata: creation_time : 2010-05-25 22:47:06 handler_name : Apple Alias Data Handler reel_name : DHC0034_1984.0040_pmaster timecode : 00:30:40:13 At least one output file must be specified THE FFV1.MKV: ffmpeg -i '/home/kieranjol/Downloads/DHC36.v210.pcm.mkv' ffmpeg version 2.8.1 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04) configuration: --prefix=/home/kieranjol/.linuxbrew/Cellar/ffmpeg/2.8.1 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=/usr/bin/gcc-4.8 --host-cflags='-Os -w -pipe -march=core2' --host-ldflags='-L/home/kieranjol/.linuxbrew/lib -Wl,-rpath,/home/kieranjol/.linuxbrew/lib' --enable-libx264 --enable-libmp3lame --enable-libvo-aacenc --enable-libxvid --enable-libfreetype --enable-ffplay --enable-vda libavutil 54. 31.100 / 54. 31.100 libavcodec 56. 60.100 / 56. 60.100 libavformat 56. 40.101 / 56. 40.101 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 40.101 / 5. 40.101 libavresample 2. 1. 0 / 2. 1. 0 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.101 / 1. 2.101 libpostproc 53. 3.100 / 53. 3.100 Guessed Channel Layout for Input Stream #0.0 : mono Guessed Channel Layout for Input Stream #0.1 : mono Guessed Channel Layout for Input Stream #0.2 : mono Guessed Channel Layout for Input Stream #0.3 : mono Input #0, matroska,webm, from '/home/kieranjol/Downloads/DHC36.v210.pcm.mkv': Metadata: TIMECODE : 00:30:40:13 ENCODER : Lavf56.40.101 Duration: 00:00:01.01, start: 0.000000, bitrate: 96188 kb/s Stream #0:0(eng): Audio: pcm_s24le, 48000 Hz, 1 channels, s32 (24 bit), 1152 kb/s (default) Metadata: CREATION_TIME : 2010-05-25 22:47:06 LANGUAGE : eng HANDLER_NAME : Apple Alias Data Handler DURATION : 00:00:01.006000000 Stream #0:1(eng): Audio: pcm_s24le, 48000 Hz, 1 channels, s32 (24 bit), 1152 kb/s (default) Metadata: CREATION_TIME : 2010-05-25 22:47:06 LANGUAGE : eng HANDLER_NAME : Apple Alias Data Handler DURATION : 00:00:01.006000000 Stream #0:2(eng): Audio: pcm_s24le, 48000 Hz, 1 channels, s32 (24 bit), 1152 kb/s (default) Metadata: CREATION_TIME : 2010-05-25 22:47:06 LANGUAGE : eng HANDLER_NAME : Apple Alias Data Handler DURATION : 00:00:01.006000000 Stream #0:3(eng): Audio: pcm_s24le, 48000 Hz, 1 channels, s32 (24 bit), 1152 kb/s (default) Metadata: CREATION_TIME : 2010-05-25 22:47:06 LANGUAGE : eng HANDLER_NAME : Apple Alias Data Handler DURATION : 00:00:01.006000000 Stream #0:4(eng): Video: ffv1 (FFV1 / 0x31564646), yuv422p10le, 720x486, SAR 1:1 DAR 40:27, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default) Metadata: CREATION_TIME : 2010-05-25 22:47:06 LANGUAGE : eng HANDLER_NAME : Apple Alias Data Handler TIMECODE : 00:30:40:13 ENCODER : Lavc56.60.100 ffv1 DURATION : 00:00:01.001000000 At least one output file must be specified Best regards, Kieran. --001a11402258ea3f920527e73d71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Dec 27, 2015 at 8:17 PM, Jerome Martinez <= jerome@mediaarea.= net> wrote:
=20 =20 =20
On 27/12/2015 21:03, Kieran O Leary wrote:
Hello,

Matroska does not currently support data tracks. From my experience working in a moving image archive, a lot of quicktime files from Final Cut Pro can end up with a timecode data track. I can't remember off the top o= f my head if AVID MC does this as well.

The timecode always seems to exist as metadata in the actual AV streams so the information isn't lost when the data track doesn't exist.

I wonder how you see the time code in your transcoded Matroska file, I see not place for it (and v210 raw stream can not contain any time code)
As far as I know, the time code information is lost during QuickTime to Matroska remuxing.

Hi Jerome,

Thanks for getting = back so quick.

The only test files = I have to hand are here: https://archive.org/details/test20100622= _v210_and_ffv1

The v210.mov from that link has a timecode track (will post full ffmpeg=20 output of both files at the bottom of the email just to be safe):
=C2=A0= =C2=A0=C2=A0 Stream #0:6(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (defa= ult)
=C2=A0=C2=A0=C2=A0 Metadata:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 crea= tion_time=C2=A0=C2=A0 : 2010-05-25 22:47:06
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 handler_name=C2=A0=C2=A0=C2=A0 : Apple Alias Data Handler
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 reel_name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : DHC00= 34_1984.0040_pmaster
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 timecode=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 00:30:40:13

This timecode info also appears in the video stream:
=C2=A0 St= ream #0:0(eng): Video: v210 (v210 / 0x30313276), yuv422p10le(bt470bg/smpte2= 40m/unknown), 720x486, 222820 kb/s, 29.85 fps, 29.97 tbr, 2997 tbn, 2997 tb= c (default)
=C2=A0=C2=A0=C2=A0 Metadata:
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 creation_time=C2=A0=C2=A0 : 2010-05-25 22:47:06
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 handler_name=C2=A0=C2=A0=C2=A0 : Apple Alias Data Handler
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 encoder=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 : Uncompressed 10 bit
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 timeco= de=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 00:30:40:13
=C2=A0=C2=A0= =C2=A0 Stream #0:1(eng): Subtitle: eia_608 (c608 / 0x38303663), 640x480, 4 = kb/s (default)

I transcoded the fil= e to ffv1.mkv and the timecode info is preserved as part of the video strea= m:
=C2=A0=C2=A0=C2=A0 Stream #0:4(eng): Video: ffv1 (FFV1 / 0x31564646), yuv422p10le,=20 720x486, SAR 1:1 DAR 40:27, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc=20 (default)
=C2=A0=C2=A0=C2=A0 Metadata:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= CREATION_TIME=C2=A0=C2=A0 : 2010-05-25 22:47:06
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 LANGUAGE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : eng
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 HANDLER_NAME=C2=A0=C2=A0=C2=A0 : Apple Alias Da= ta Handler
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TIMECODE=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 : 00:30:40:13
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENCOD= ER=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Lavc56.60.100 ffv1
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DURATION=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 : 00:00:01.001000000

My comm= and line was=C2=A0 ffmpeg -i '/home/kieranjol/Downloads/DHC36.v210.pcm.= mov' -c:v ffv1 -level 3 -g 1 -t 1 -c:a copy -map 0:a -map 0:v '/hom= e/kieranjol/Downloads/DHC36.v210.pcm.mkv'



Here's the ffmpeg = -i=C2=A0 from the v210 original, and the ffv1.mkv will follow.

ffmpe= g -i '/home/kieranjol/Downloads/DHC36.v210.pcm.mov'
ffmpeg vers= ion 2.8.1 Copyright (c) 2000-2015 the FFmpeg developers
=C2=A0 built wit= h gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04)
=C2=A0 configuration: --prefix= =3D/home/kieranjol/.linuxbrew/Cellar/ffmpeg/2.8.1 --enable-shared --enable-pthreads --enable-gpl --enable-version3=20 --enable-hardcoded-tables --enable-avresample --cc=3D/usr/bin/gcc-4.8=20 --host-cflags=3D'-Os -w -pipe -march=3Dcore2' --host-ldflags=3D'= ;-L/home/kieranjol/.linuxbrew/lib -Wl,-rpath,/home/kieranjol/.linuxbrew/lib= ' --enable-libx264 --enable-libmp3lame --enable-libvo-aacenc=20 --enable-libxvid --enable-libfreetype --enable-ffplay --enable-vda
=C2= =A0 libavutil=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 54. 31.100 / 54. 31.100
=C2= =A0 libavcodec=C2=A0=C2=A0=C2=A0=C2=A0 56. 60.100 / 56. 60.100
=C2=A0 li= bavformat=C2=A0=C2=A0=C2=A0 56. 40.101 / 56. 40.101
=C2=A0 libavdevice= =C2=A0=C2=A0=C2=A0 56.=C2=A0 4.100 / 56.=C2=A0 4.100
=C2=A0 libavfilter= =C2=A0=C2=A0=C2=A0=C2=A0 5. 40.101 /=C2=A0 5. 40.101
=C2=A0 libavresampl= e=C2=A0=C2=A0 2.=C2=A0 1.=C2=A0 0 /=C2=A0 2.=C2=A0 1.=C2=A0 0
=C2=A0 lib= swscale=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3.=C2=A0 1.101 /=C2=A0 3.=C2=A0 1.101=
=C2=A0 libswresample=C2=A0=C2=A0 1.=C2=A0 2.101 /=C2=A0 1.=C2=A0 2.101<= br>=C2=A0 libpostproc=C2=A0=C2=A0=C2=A0 53.=C2=A0 3.100 / 53.=C2=A0 3.100Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/home/kieranjol/Downloads/DH= C36.v210.pcm.mov':
=C2=A0 Metadata:
=C2=A0=C2=A0=C2=A0 creation_t= ime=C2=A0=C2=A0 : 2010-05-25 22:46:56
=C2=A0=C2=A0=C2=A0 timecode=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 00:30:40:13
=C2=A0 Duration: 00:0= 0:09.91, start: 0.040375, bitrate: 230674 kb/s
=C2=A0=C2=A0=C2=A0 Stream= #0:0(eng): Video: v210 (v210 / 0x30313276), yuv422p10le(bt470bg/smpte240m/= unknown), 720x486, 222820 kb/s, 29.85 fps, 29.97 tbr, 2997 tbn, 2997 tbc (d= efault)
=C2=A0=C2=A0=C2=A0 Metadata:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 c= reation_time=C2=A0=C2=A0 : 2010-05-25 22:47:06
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 handler_name=C2=A0=C2=A0=C2=A0 : Apple Alias Data Handler
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 encoder=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 : Uncompressed 10 bit
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 timecode=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 00:30:40:13
=C2=A0=C2=A0=C2=A0= Stream #0:1(eng): Subtitle: eia_608 (c608 / 0x38303663), 640x480, 4 kb/s (= default)
=C2=A0=C2=A0=C2=A0 Metadata:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = creation_time=C2=A0=C2=A0 : 2010-05-25 22:47:06
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 handler_name=C2=A0=C2=A0=C2=A0 : Apple Alias Data Handler
=C2=A0= =C2=A0=C2=A0 Stream #0:2(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 = Hz, mono, s32 (24 bit), 1152 kb/s (default)
=C2=A0=C2=A0=C2=A0 Metadata:=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 creation_time=C2=A0=C2=A0 : 2010-05-25 2= 2:47:06
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 handler_name=C2=A0=C2=A0=C2=A0 : = Apple Alias Data Handler
=C2=A0=C2=A0=C2=A0 Stream #0:3(eng): Audio: pcm= _s24le (in24 / 0x34326E69), 48000 Hz, mono, s32 (24 bit), 1152 kb/s (defaul= t)
=C2=A0=C2=A0=C2=A0 Metadata:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 creati= on_time=C2=A0=C2=A0 : 2010-05-25 22:47:06
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= handler_name=C2=A0=C2=A0=C2=A0 : Apple Alias Data Handler
=C2=A0=C2=A0= =C2=A0 Stream #0:4(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mo= no, s32 (24 bit), 1152 kb/s (default)
=C2=A0=C2=A0=C2=A0 Metadata:
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 creation_time=C2=A0=C2=A0 : 2010-05-25 22:47= :06
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 handler_name=C2=A0=C2=A0=C2=A0 : Appl= e Alias Data Handler
=C2=A0=C2=A0=C2=A0 Stream #0:5(eng): Audio: pcm_s24= le (in24 / 0x34326E69), 48000 Hz, mono, s32 (24 bit), 1152 kb/s (default)=C2=A0=C2=A0=C2=A0 Metadata:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 creation_t= ime=C2=A0=C2=A0 : 2010-05-25 22:47:06
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 han= dler_name=C2=A0=C2=A0=C2=A0 : Apple Alias Data Handler
=C2=A0=C2=A0=C2= =A0 Stream #0:6(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
= =C2=A0=C2=A0=C2=A0 Metadata:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 creation_tim= e=C2=A0=C2=A0 : 2010-05-25 22:47:06
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 handl= er_name=C2=A0=C2=A0=C2=A0 : Apple Alias Data Handler
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 reel_name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : DHC0034_1984.0= 040_pmaster
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 timecode=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 : 00:30:40:13
At least one output file must be spe= cified

THE FFV1.MKV:
=C2=A0ffmpe= g -i '/home/kieranjol/Downloads/DHC36.v210.pcm.mkv'
ffmpeg vers= ion 2.8.1 Copyright (c) 2000-2015 the FFmpeg developers
=C2=A0 built wit= h gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04)
=C2=A0 configuration: --prefix= =3D/home/kieranjol/.linuxbrew/Cellar/ffmpeg/2.8.1 --enable-shared --enable-pthreads --enable-gpl --enable-version3=20 --enable-hardcoded-tables --enable-avresample --cc=3D/usr/bin/gcc-4.8=20 --host-cflags=3D'-Os -w -pipe -march=3Dcore2' --host-ldflags=3D'= ;-L/home/kieranjol/.linuxbrew/lib -Wl,-rpath,/home/kieranjol/.linuxbrew/lib= ' --enable-libx264 --enable-libmp3lame --enable-libvo-aacenc=20 --enable-libxvid --enable-libfreetype --enable-ffplay --enable-vda
=C2= =A0 libavutil=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 54. 31.100 / 54. 31.100
=C2= =A0 libavcodec=C2=A0=C2=A0=C2=A0=C2=A0 56. 60.100 / 56. 60.100
=C2=A0 li= bavformat=C2=A0=C2=A0=C2=A0 56. 40.101 / 56. 40.101
=C2=A0 libavdevice= =C2=A0=C2=A0=C2=A0 56.=C2=A0 4.100 / 56.=C2=A0 4.100
=C2=A0 libavfilter= =C2=A0=C2=A0=C2=A0=C2=A0 5. 40.101 /=C2=A0 5. 40.101
=C2=A0 libavresampl= e=C2=A0=C2=A0 2.=C2=A0 1.=C2=A0 0 /=C2=A0 2.=C2=A0 1.=C2=A0 0
=C2=A0 lib= swscale=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3.=C2=A0 1.101 /=C2=A0 3.=C2=A0 1.101=
=C2=A0 libswresample=C2=A0=C2=A0 1.=C2=A0 2.101 /=C2=A0 1.=C2=A0 2.101<= br>=C2=A0 libpostproc=C2=A0=C2=A0=C2=A0 53.=C2=A0 3.100 / 53.=C2=A0 3.100Guessed Channel Layout for=C2=A0 Input Stream #0.0 : mono
Guessed Chan= nel Layout for=C2=A0 Input Stream #0.1 : mono
Guessed Channel Layout for= =C2=A0 Input Stream #0.2 : mono
Guessed Channel Layout for=C2=A0 Input S= tream #0.3 : mono
Input #0, matroska,webm, from '/home/kieranjol/Dow= nloads/DHC36.v210.pcm.mkv':
=C2=A0 Metadata:
=C2=A0=C2=A0=C2=A0 T= IMECODE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 00:30:40:13
=C2=A0= =C2=A0=C2=A0 ENCODER=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Lavf= 56.40.101
=C2=A0 Duration: 00:00:01.01, start: 0.000000, bitrate: 96188 = kb/s
=C2=A0=C2=A0=C2=A0 Stream #0:0(eng): Audio: pcm_s24le, 48000 Hz, 1 = channels, s32 (24 bit), 1152 kb/s (default)
=C2=A0=C2=A0=C2=A0 Metadata:=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CREATION_TIME=C2=A0=C2=A0 : 2010-05-25 2= 2:47:06
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LANGUAGE=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 : eng
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HANDLER_NAME=C2= =A0=C2=A0=C2=A0 : Apple Alias Data Handler
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 DURATION=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 00:00:01.006000000=
=C2=A0=C2=A0=C2=A0 Stream #0:1(eng): Audio: pcm_s24le, 48000 Hz, 1 chan= nels, s32 (24 bit), 1152 kb/s (default)
=C2=A0=C2=A0=C2=A0 Metadata:
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CREATION_TIME=C2=A0=C2=A0 : 2010-05-25 22:47= :06
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LANGUAGE=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 : eng
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HANDLER_NAME=C2=A0= =C2=A0=C2=A0 : Apple Alias Data Handler
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 D= URATION=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 00:00:01.006000000
= =C2=A0=C2=A0=C2=A0 Stream #0:2(eng): Audio: pcm_s24le, 48000 Hz, 1 channels= , s32 (24 bit), 1152 kb/s (default)
=C2=A0=C2=A0=C2=A0 Metadata:
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 CREATION_TIME=C2=A0=C2=A0 : 2010-05-25 22:47:06=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LANGUAGE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 : eng
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HANDLER_NAME=C2=A0=C2= =A0=C2=A0 : Apple Alias Data Handler
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DURA= TION=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 00:00:01.006000000
=C2= =A0=C2=A0=C2=A0 Stream #0:3(eng): Audio: pcm_s24le, 48000 Hz, 1 channels, s= 32 (24 bit), 1152 kb/s (default)
=C2=A0=C2=A0=C2=A0 Metadata:
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 CREATION_TIME=C2=A0=C2=A0 : 2010-05-25 22:47:06=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LANGUAGE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 : eng
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HANDLER_NAME=C2=A0=C2=A0= =C2=A0 : Apple Alias Data Handler
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DURATIO= N=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 00:00:01.006000000
=C2=A0= =C2=A0=C2=A0 Stream #0:4(eng): Video: ffv1 (FFV1 / 0x31564646), yuv422p10le,=20 720x486, SAR 1:1 DAR 40:27, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc=20 (default)
=C2=A0=C2=A0=C2=A0 Metadata:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= CREATION_TIME=C2=A0=C2=A0 : 2010-05-25 22:47:06
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 LANGUAGE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : eng
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 HANDLER_NAME=C2=A0=C2=A0=C2=A0 : Apple Alias Da= ta Handler
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TIMECODE=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 : 00:30:40:13
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENCOD= ER=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Lavc56.60.100 ffv1
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DURATION=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 : 00:00:01.001000000
At least one output file must be specified

Best regards,

Kiera= n.
--001a11402258ea3f920527e73d71-- From nobody Sun Dec 27 13:15:13 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E7F1A6F1E for ; Sun, 27 Dec 2015 13:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 oSMTWGAgjzs7 for ; Sun, 27 Dec 2015 13:15:10 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 1741C1A6F1D for ; Sun, 27 Dec 2015 13:15:10 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id p203so192434901lfa.0 for ; Sun, 27 Dec 2015 13:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=aEAdsJVdMJezlsSt7UhH2IWWTg0to8Qk1qtUQI3vL1g=; b=eBxK7bKYhWvArkZpWSCDzEPE5LzYl9UoqlZTtcnmB0xWmMbWQsHLIfRlHOIUYe3J6s nJUjUM4ZOr9gESub2wASN0rk3JiP3Hvc4asPsvn3qQPxWVApTtWdihXp2OMQ+blr12oh OtDgeRg1mo4WYjDH3IvUtDcbGatYCdkQ8mMljwvGxCOll0NdqlTO3KHbqoMthFEAt0BN VTWdvI4Ee6TS+xR1YBrYTlF6MqokPE+pgJA4aZ1BHOEQ6emYgvNy1msBCMUM/rkPQgru BMmUK+6cGz2nmkbxN988wQd0/iaGMrEDCwdz9MuDzLt6aWYr7lGkNQRty5xMwGVwzxaZ bT8w== MIME-Version: 1.0 X-Received: by 10.25.29.73 with SMTP id d70mr13030833lfd.137.1451250908237; Sun, 27 Dec 2015 13:15:08 -0800 (PST) Received: by 10.25.78.206 with HTTP; Sun, 27 Dec 2015 13:15:07 -0800 (PST) In-Reply-To: References: <56804743.9050209@mediaarea.net> Date: Sun, 27 Dec 2015 21:15:07 +0000 Message-ID: From: Kieran O Leary To: Jerome Martinez , cellar@ietf.org Content-Type: multipart/alternative; boundary=001a114022bcdd98f80527e7aef3 Archived-At: Subject: Re: [Cellar] Data stream support in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 27 Dec 2015 21:15:12 -0000 --001a114022bcdd98f80527e7aef3 Content-Type: text/plain; charset=UTF-8 P.S It shows up as TIMECODE in Mediainfo in the video section of the ffv1.mkv. It doesn't appear anywhere else (not in General) it only shows up in ffprobe in the following format (using -show_streams) [STREAM] index=4 codec_name=ffv1 codec_long_name=FFmpeg video codec #1 profile=unknown codec_type=video codec_time_base=1/1000 codec_tag_string=FFV1 codec_tag=0x31564646 width=720 height=486 coded_width=720 coded_height=486 has_b_frames=0 sample_aspect_ratio=1:1 display_aspect_ratio=40:27 pix_fmt=yuv422p10le level=-99 color_range=N/A color_space=unknown color_transfer=unknown color_primaries=unknown chroma_location=unspecified timecode=N/A refs=1 id=N/A r_frame_rate=2997/100 avg_frame_rate=2997/100 time_base=1/1000 start_pts=0 start_time=0.000000 duration_ts=N/A duration=N/A bit_rate=N/A max_bit_rate=N/A bits_per_raw_sample=10 nb_frames=N/A nb_read_frames=N/A nb_read_packets=N/A DISPOSITION:default=1 DISPOSITION:dub=0 DISPOSITION:original=0 DISPOSITION:comment=0 DISPOSITION:lyrics=0 DISPOSITION:karaoke=0 DISPOSITION:forced=0 DISPOSITION:hearing_impaired=0 DISPOSITION:visual_impaired=0 DISPOSITION:clean_effects=0 DISPOSITION:attached_pic=0 TAG:CREATION_TIME=2010-05-25 22:47:06 TAG:LANGUAGE=eng TAG:HANDLER_NAME=Apple Alias Data Handler TAG:TIMECODE=00:30:40:13 TAG:ENCODER=Lavc56.60.100 ffv1 TAG:DURATION=00:00:01.001000000 [/STREAM] --001a114022bcdd98f80527e7aef3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

P.S

It shows up as TIMECODE in Mediainfo in the video section = of the ffv1.mkv. It doesn't appear anywhere else (not in General)
it only shows up in ffprobe in the following= format (using -show_streams)
[STREAM]
index=3D4
codec_name=3Dffv1=
codec_long_name=3DFFmpeg video codec #1
profile=3Dunknown
codec_t= ype=3Dvideo
codec_time_base=3D1/1000
codec_tag_string=3DFFV1
codec= _tag=3D0x31564646
width=3D720
height=3D486
coded_width=3D720
co= ded_height=3D486
has_b_frames=3D0
sample_aspect_ratio=3D1:1
displa= y_aspect_ratio=3D40:27
pix_fmt=3Dyuv422p10le
level=3D-99
color_ran= ge=3DN/A
color_space=3Dunknown
color_transfer=3Dunknown
color_prim= aries=3Dunknown
chroma_location=3Dunspecified
timecode=3DN/A
refs= =3D1
id=3DN/A
r_frame_rate=3D2997/100
avg_frame_rate=3D2997/100time_base=3D1/1000
start_pts=3D0
start_time=3D0.000000
duration_t= s=3DN/A
duration=3DN/A
bit_rate=3DN/A
max_bit_rate=3DN/A
bits_p= er_raw_sample=3D10
nb_frames=3DN/A
nb_read_frames=3DN/A
nb_read_pa= ckets=3DN/A
DISPOSITION:default=3D1
DISPOSITION:dub=3D0
DISPOSITIO= N:original=3D0
DISPOSITION:comment=3D0
DISPOSITION:lyrics=3D0
DISP= OSITION:karaoke=3D0
DISPOSITION:forced=3D0
DISPOSITION:hearing_impair= ed=3D0
DISPOSITION:visual_impaired=3D0
DISPOSITION:clean_effects=3D0<= br>DISPOSITION:attached_pic=3D0
TAG:CREATION_TIME=3D2010-05-25 22:47:06<= br>TAG:LANGUAGE=3Deng
TAG:HANDLER_NAME=3DApple Alias Data Handler
TAG= :TIMECODE=3D00:30:40:13
TAG:ENCODER=3DLavc56.60.100 ffv1
TAG:DURATION= =3D00:00:01.001000000
[/STREAM]

--001a114022bcdd98f80527e7aef3-- From nobody Sun Dec 27 13:24:43 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFB31A6F30 for ; Sun, 27 Dec 2015 13:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.113 X-Spam-Level: X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 PjgTsdmWUNOj for ; Sun, 27 Dec 2015 13:24:42 -0800 (PST) Received: from liselle.bunkus.org (liselle.bunkus.org [IPv6:2a01:4f8:151:7310::105:1]) (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 8EFA11A6F22 for ; Sun, 27 Dec 2015 13:24:41 -0800 (PST) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 50CAF3BB2C7; Sun, 27 Dec 2015 22:24:39 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 3CE113BB2BC for ; Sun, 27 Dec 2015 22:24:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2015100101; t=1451251477; bh=p7QAb9PNujwgJ8vkYZdSyOYkQFWVgMC0igpv/rwsxD8=; h=Date:From:To:Subject:References:In-Reply-To; b=RVv7XYycj0DFUtLkppo2vlo5XXbQZ+TCH4gr3T6o1yEXrKiykhfO54oyThlO4xHMj u0nqJ14imp5JJS49pXCTaEP+gAmxI025q2ejSXlM9kHdi9RdjPtZLukTkJ3q0wJXDc CY/ZdBzX9esSFVohpaBPofkxLGvEuQZKMpdleL0O8I9DSo0SBbnVaYhcMB9c4ZHfx9 WAF0VHnFOTn34NPoas3RW8rMmRzC3Xsy71+dolxu/WLTigdK3gTccD9O5/13tZZGiy be8k0AHNmEx44H1mHAWuXIC8DhC9/Oyuue+vxUeLua3fXzeb6uB/MJbZxa37FXgA5G n/Ror0gAsrLRgfFsTP9zvySpOxye71doPaMSDWebuhGtLVfKgmQYfETsIp7U0Ay22m /9uJPzkk4+TGQ+W4t9GO6gkb9LaWKgTLZOgosjbIAhWHd4qLiLLnC4XeTNJm6yaBdw GoYKcaWFBLFhGRBcdFLp5xRSMxFtmcXjI/2cZHkqF7sXEQnn0nVdhG8hEqjF5NaGlx 148nLPrfxGIxK5VmqFl4GYMCyLniOCd35T59bEd2LFX7jWAoSVX0QSxB9hKD/6a7ZJ jPsfXCQt6zXic3uuQiF+iOTyVrh0tjx6lVcNdOI6vMnhztyF/qTaZ8yFoGhPzILk89 ThbRG3ca/WjQ0u3GO5ZKjLCk= Received: by sweet-chili.local (Postfix, from userid 1000) id 3636C510FE5; Sun, 27 Dec 2015 22:23:21 +0100 (CET) Date: Sun, 27 Dec 2015 22:23:21 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20151227212320.GA3494@bunkus.org> References: <56804743.9050209@mediaarea.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] Data stream support in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 27 Dec 2015 21:24:43 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, > TAG:CREATION_TIME=2010-05-25 22:47:06 > TAG:LANGUAGE=eng > TAG:HANDLER_NAME=Apple Alias Data Handler > TAG:TIMECODE=00:30:40:13 > TAG:ENCODER=Lavc56.60.100 ffv1 > TAG:DURATION=00:00:01.001000000 Well. If it's a tag then a data track wouldn't be a good fit for such information anyway. Matroska differentiates between information that is timestamped and needs synchronization on the one hand and general information applying to the whole file on the other. These tags output by ffmpeg seem to be information of the latter kind. They don't differ from frame to frame, they don't have to be interleaved with other frames in order to avoid seeking. Therefore the best way to deal with those is to store them as tags in Matroska. I don't think that it should be ffmpeg's place to convert such information to tags automatically (or at least not by default, maybe with an option), though. Such a conversion would be easy to achieve outside of ffmpeg with some scripting. First convert as you've already done. Next run ffprobe, extract the lines starting with "TAG:", create a Matroska tags XML file for it and use mkvpropedit to attach those tags to the converted file. Kind regards, mosu --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWgFbEAAoJEHSvAK3y4yyFiuUQAL7qoO3Krzvz64GiyBpqxCyK qkJUd3is3th1YMQihREB2FB7Cd6vVVpHFJoL2fa8Mik+vq9+yqzNP5QzaoqbZj8m SxX0sbauFAAGfXNASTHWyhibgNaK5bOfDQlM/+5K4OtfakEBOuk+2Tj51RTqpuq5 8VGeCddwj5JU9sNE/u46JFHTbhbtYGRUKnq1T6eFsA+pYeIs2BYehN3S4z05zl0h MYd3Ti7NYBZKjKQU0vouchoIuw5xgmniMLIUAdGiGp+DWIyrjW3bmpE8mAQBXeou hsIA5PcEdI5/ZYanK0SBs/ej9rlTifcYQFA65i3NHPqVPkmkeZx7uDC+r/gLx8Ge ku27WTFpN5PROA6w0/FLGhwuaz+7nZF+4J9zM2gLaTgiLC+GqgOfNLSL+FyL0657 O4dj0nkmPwyIxJxPH+lYm0sI3Dd6DcVBv5+tzY1rWX0+AcD+NWg74OAECaUTocCv tcbTDIHzUfBVfBvaOgYrm+GySJG++jDlGmKi6WA8q1P3AjddHtZcCli+Ev5ZKf5l 4lD5NMW7sKeBW6nQtdJ1y+KFMAFQ0HX7ub+9rbiHQYohnkVBoSCnfKVrnIQX/Ftx 1a0L9XeEcQNI0RF9k7MBE766qAAua+m9IUs7nNzxHuhZg/28qmFdWqFTCjG2ozNs F7sAzw8isN2di7qLbudG =jwPB -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From nobody Sun Dec 27 13:35:00 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD451A6F53 for ; Sun, 27 Dec 2015 13:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 kyuqRhrVBrXV for ; Sun, 27 Dec 2015 13:34:57 -0800 (PST) Received: from 11.mo1.mail-out.ovh.net (11.mo1.mail-out.ovh.net [188.165.48.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5C11A6F51 for ; Sun, 27 Dec 2015 13:34:57 -0800 (PST) Received: from mail183.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo1.mail-out.ovh.net (Postfix) with SMTP id 52896FFAF3A for ; Sun, 27 Dec 2015 22:34:55 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 27 Dec 2015 23:34:54 +0200 Received: from p4fe1ee8b.dip0.t-ipconnect.de (HELO ?192.168.2.103?) (zen@mediaarea.net@79.225.238.139) by ns0.ovh.net with SMTP; 27 Dec 2015 23:34:52 +0200 To: Kieran O Leary , cellar@ietf.org References: <56804743.9050209@mediaarea.net> From: Jerome Martinez Message-ID: <56805978.3000503@mediaarea.net> Date: Sun, 27 Dec 2015 22:34:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 6448028768286281874 X-Ovh-Remote: 79.225.238.139 (p4fe1ee8b.dip0.t-ipconnect.de) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -100 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedrheefucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedrheehgddugeehucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Archived-At: Subject: Re: [Cellar] Data stream support in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 27 Dec 2015 21:34:59 -0000 On 27/12/2015 21:43, Kieran O Leary wrote: > > I transcoded the file to ffv1.mkv and the timecode info is preserved > as part of the video stream: > Stream #0:4(eng): Video: ffv1 (FFV1 / 0x31564646), yuv422p10le, > 720x486, SAR 1:1 DAR 40:27, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default) > Metadata: > CREATION_TIME : 2010-05-25 22:47:06 > LANGUAGE : eng > HANDLER_NAME : Apple Alias Data Handler > TIMECODE : 00:30:40:13 > ENCODER : Lavc56.60.100 ffv1 > DURATION : 00:00:01.001000000 > > My command line was ffmpeg -i > '/home/kieranjol/Downloads/DHC36.v210.pcm.mov' -c:v ffv1 -level 3 -g 1 > -t 1 -c:a copy -map 0:a -map 0:v > '/home/kieranjol/Downloads/DHC36.v210.pcm.mkv' I see, FFmpeg transforms the time code track to a piece of metadata. I don't think this is something "standard" (for Matroska) and I see an issue: it works only for an unique timecode value. if your time code track contains more than 1 time code value (QuickTime has 2 "modes" for time codes: 1/ "striped", contains an unique time code value, the one of the first frame, and timecode value of other frames are computed from the time code of the first frame + frame count; 2/ not "striped", contains one time code value per frame, so it can handle discontinuities), I think you lose other time codes values (I'll test with such file later next week). We also lose the time code frame rate (it may look like weird, but sometimes the time code framerate is not same as the video framerate) So current method is a (not bad) workaround, but nothing safe for LossLess Archiving and Realtime transmission. From nobody Sun Dec 27 13:46:52 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131E41A6F65 for ; Sun, 27 Dec 2015 13:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 QBU8iTctdJyh for ; Sun, 27 Dec 2015 13:46:49 -0800 (PST) Received: from 20.mo1.mail-out.ovh.net (20.mo1.mail-out.ovh.net [188.165.45.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7111A6F63 for ; Sun, 27 Dec 2015 13:46:48 -0800 (PST) Received: from mail183.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo1.mail-out.ovh.net (Postfix) with SMTP id 1DFBDFFB25E for ; Sun, 27 Dec 2015 22:46:47 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 27 Dec 2015 23:46:46 +0200 Received: from p4fe1ee8b.dip0.t-ipconnect.de (HELO ?192.168.2.103?) (zen@mediaarea.net@79.225.238.139) by ns0.ovh.net with SMTP; 27 Dec 2015 23:46:44 +0200 To: cellar@ietf.org References: <56804743.9050209@mediaarea.net> <20151227212320.GA3494@bunkus.org> From: Jerome Martinez Message-ID: <56805C40.1060403@mediaarea.net> Date: Sun, 27 Dec 2015 22:46:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20151227212320.GA3494@bunkus.org> Content-Type: multipart/alternative; boundary="------------060909070302040302050909" X-Ovh-Tracer-Id: 6648438950522982546 X-Ovh-Remote: 79.225.238.139 (p4fe1ee8b.dip0.t-ipconnect.de) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedrheefucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedrheehgddugeekucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Data stream support in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 27 Dec 2015 21:46:51 -0000 This is a multi-part message in MIME format. --------------060909070302040302050909 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 27/12/2015 22:23, Moritz Bunkus wrote: > Hey, > >> TAG:CREATION_TIME=2010-05-25 22:47:06 >> TAG:LANGUAGE=eng >> TAG:HANDLER_NAME=Apple Alias Data Handler >> TAG:TIMECODE=00:30:40:13 >> TAG:ENCODER=Lavc56.60.100 ffv1 >> TAG:DURATION=00:00:01.001000000 > Well. If it's a tag then a data track wouldn't be a good fit for such > information anyway. > > Matroska differentiates between information that is timestamped and > needs synchronization on the one hand and general information applying > to the whole file on the other. > > These tags output by ffmpeg seem to be information of the latter > kind. They don't differ from frame to frame, they don't have to be > interleaved with other frames in order to avoid seeking. In that case, yes, because the time code track is "stripped" (QuickTime wording). It is not always the case: - QuickTime time code can contain one time code value per frame, it can be interleaved with video (time code packet 0 with frame 0 time code value, video packet 0, time code packet 1 with frame 1 time code value, video packet 1...) or all in one block (one unique packet with all time code values in one shot, the decoder/demuxer must keep all time codes in RAM for sending the right timecode at the right time) - More generally speaking, time codes can be transported by other means than QuickTime time code tracks, e.g. Ancillary data https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.1364-3-201510-I!!PDF-E.pdf , there is one Ancillary data packet per corresponding video frame, so interleaved. so such data content could be "information that is timestamped and needs synchronization" and we need to specify a CodecID for both QuickTime non stripped time code tracks and for BT.1364 tracks if we want to fully keep such data during remuxing. > > Therefore the best way to deal with those is to store them as tags in > Matroska. I don't think that it should be ffmpeg's place to convert such > information to tags automatically (or at least not by default, maybe > with an option), though. > > Such a conversion would be easy to achieve outside of ffmpeg with some > scripting. First convert as you've already done. Next run ffprobe, > extract the lines starting with "TAG:", create a Matroska tags XML file > for it and use mkvpropedit to attach those tags to the converted file. But TIMECODE is not a "standard" tag for the moment, and it may be something important for some people to be sure to retrieve such information for sure. > > Kind regards, > mosu > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --------------060909070302040302050909 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

On 27/12/2015 22:23, Moritz Bunkus wrote:
Hey,


TAG:CREATION_TIME=2010-05-25 22:47:06
TAG:LANGUAGE=eng
TAG:HANDLER_NAME=Apple Alias Data Handler
TAG:TIMECODE=00:30:40:13
TAG:ENCODER=Lavc56.60.100 ffv1
TAG:DURATION=00:00:01.001000000

Well. If it's a tag then a data track wouldn't be a good fit for such
information anyway.

Matroska differentiates between information that is timestamped and
needs synchronization on the one hand and general information applying
to the whole file on the other.

These tags output by ffmpeg seem to be information of the latter
kind. They don't differ from frame to frame, they don't have to be
interleaved with other frames in order to avoid seeking.

In that case, yes, because the time code track is "stripped" (QuickTime wording).
It is not always the case:
- QuickTime time code can contain one time code value per frame, it can be interleaved with video (time code packet 0 with frame 0 time code value, video packet 0, time code packet 1 with frame 1 time code value, video packet 1...) or all in one block (one unique packet with all time code values in one shot, the decoder/demuxer must keep all time codes in RAM for sending the right timecode at the right time)
- More generally speaking, time codes can be transported by other means than QuickTime time code tracks, e.g. Ancillary data https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.1364-3-201510-I!!PDF-E.pdf , there is one Ancillary data packet per corresponding video frame, so interleaved.

so such data content could be "information that is timestamped and needs synchronization" and we need to specify a CodecID for both QuickTime non stripped time code tracks and for BT.1364 tracks if we want to fully keep such data during remuxing.



Therefore the best way to deal with those is to store them as tags in
Matroska. I don't think that it should be ffmpeg's place to convert such
information to tags automatically (or at least not by default, maybe
with an option), though.

Such a conversion would be easy to achieve outside of ffmpeg with some
scripting. First convert as you've already done. Next run ffprobe,
extract the lines starting with "TAG:", create a Matroska tags XML file
for it and use mkvpropedit to attach those tags to the converted file.

But TIMECODE is not a "standard" tag for the moment, and it may be something important for some people to be sure to retrieve such information for sure.


Kind regards,
mosu



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

--------------060909070302040302050909-- From nobody Sun Dec 27 14:08:27 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4A41A6F8E for ; Sun, 27 Dec 2015 14:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 1CCGtScfbNIZ for ; Sun, 27 Dec 2015 14:08:23 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 75C001A6F8D for ; Sun, 27 Dec 2015 14:08:22 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id bc4so84582925lbc.2 for ; Sun, 27 Dec 2015 14:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5kagPL+e42ucK2skU0Rwg6F9znSx8wtMET2+kfbe7Q4=; b=r2Ara1jlaJG2rrFOFm+4YKGa83JU5l4oDpPp7H/WkAL/7wmnQJJgSi7crnOOWnhLQF pPGQpNNuH+kzKglU3/9LlsXGYcaJP0oMIkc+9q+vQIAJ6SzO4QrqHHeQaFCXVlCVUvld NGqnwaUTl1/X9cOER+rEgqDnpoptGJL4ofCYxGBKXPmBULcQMqARod5pREe4JYEm20zp lhSIT5neuV3x+2r2/973skrOqVxN/YUzrMTp7kuhBQ2B+gQj9Qpf4nvSk5En3U8vDM0g HmDK1XXCYTSOti3wHX+Ammypc7RqVK8QszM3hOCVIJKgusCnY+PqwVmYOr0/ytHzBE/z QBqQ== MIME-Version: 1.0 X-Received: by 10.112.140.34 with SMTP id rd2mr18768651lbb.24.1451254100634; Sun, 27 Dec 2015 14:08:20 -0800 (PST) Received: by 10.25.78.206 with HTTP; Sun, 27 Dec 2015 14:08:20 -0800 (PST) In-Reply-To: <56805C40.1060403@mediaarea.net> References: <56804743.9050209@mediaarea.net> <20151227212320.GA3494@bunkus.org> <56805C40.1060403@mediaarea.net> Date: Sun, 27 Dec 2015 22:08:20 +0000 Message-ID: From: Kieran O Leary To: cellar@ietf.org Content-Type: multipart/alternative; boundary=001a11c2662025b8940527e86d2c Archived-At: Subject: Re: [Cellar] Data stream support in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 27 Dec 2015 22:08:24 -0000 --001a11c2662025b8940527e86d2c Content-Type: text/plain; charset=UTF-8 It seems like it's a tag in the v210 stream as well, or is ffmpeg generating this tag based on the timecode track? It seems like in my case, the timecode track is ignored and the timecode tag from the v210 is carried over as a tag to the ffv1 stream in the .mkv? So it seems like the tag is carried over from the v210 stream to the the ffv1 stream, ignoring the data timecode track? Just FYI, here's the ffprobe of the quicktime timecode track, followed by the quicktime v210 output: [STREAM] index=6 codec_name=unknown codec_long_name=unknown profile=unknown codec_type=data codec_time_base=1/30 codec_tag_string=tmcd codec_tag=0x64636d74 id=N/A r_frame_rate=0/0 avg_frame_rate=0/0 time_base=1/2997 start_pts=-121 start_time=-0.040374 duration_ts=29700 duration=9.909910 bit_rate=3 max_bit_rate=N/A bits_per_raw_sample=N/A nb_frames=1 nb_read_frames=N/A nb_read_packets=N/A DISPOSITION:default=1 DISPOSITION:dub=0 DISPOSITION:original=0 DISPOSITION:comment=0 DISPOSITION:lyrics=0 DISPOSITION:karaoke=0 DISPOSITION:forced=0 DISPOSITION:hearing_impaired=0 DISPOSITION:visual_impaired=0 DISPOSITION:clean_effects=0 DISPOSITION:attached_pic=0 TAG:creation_time=2010-05-25 22:47:06 TAG:language=eng TAG:handler_name=Apple Alias Data Handler TAG:reel_name=DHC0034_1984.0040_pmaster TAG:timecode=00:30:40:13 [/STREAM] [STREAM] index=0 codec_name=v210 codec_long_name=Uncompressed 4:2:2 10-bit profile=unknown codec_type=video codec_time_base=1/2997 codec_tag_string=v210 codec_tag=0x30313276 width=720 height=486 coded_width=720 coded_height=486 has_b_frames=0 sample_aspect_ratio=0:1 display_aspect_ratio=0:1 pix_fmt=yuv422p10le level=-99 color_range=N/A color_space=bt470bg color_transfer=unknown color_primaries=smpte240m chroma_location=unspecified timecode=N/A refs=1 id=N/A r_frame_rate=2997/100 avg_frame_rate=893106/29921 time_base=1/2997 start_pts=-121 start_time=-0.040374 duration_ts=29921 duration=9.983650 bit_rate=222820111 max_bit_rate=N/A bits_per_raw_sample=10 nb_frames=298 nb_read_frames=N/A nb_read_packets=N/A DISPOSITION:default=1 DISPOSITION:dub=0 DISPOSITION:original=0 DISPOSITION:comment=0 DISPOSITION:lyrics=0 DISPOSITION:karaoke=0 DISPOSITION:forced=0 DISPOSITION:hearing_impaired=0 DISPOSITION:visual_impaired=0 DISPOSITION:clean_effects=0 DISPOSITION:attached_pic=0 TAG:creation_time=2010-05-25 22:47:06 TAG:language=eng TAG:handler_name=Apple Alias Data Handler TAG:encoder=Uncompressed 10 bit TAG:timecode=00:30:40:13 [/STREAM] --001a11c2662025b8940527e86d2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It seems like it's a tag in the v210 stream as well, o= r is ffmpeg generating this tag based on the timecode track? It seems like = in my case, the timecode track is ignored and the timecode tag from the v21= 0 is carried over as a tag to the ffv1 stream in the .mkv?
So it seems l= ike the tag is carried over from the v210 stream to the the ffv1 stream, ig= noring the data timecode track?=C2=A0

Just FYI, here's the ffpr= obe of the quicktime timecode track, followed by the quicktime v210 output:=
[STREAM]
index=3D6
codec_name=3Dunknown
codec_long_name=3Dunkn= own
profile=3Dunknown
codec_type=3Ddata
codec_time_base=3D1/30
= codec_tag_string=3Dtmcd
codec_tag=3D0x64636d74
id=3DN/A
r_frame_ra= te=3D0/0
avg_frame_rate=3D0/0
time_base=3D1/2997
start_pts=3D-121<= br>start_time=3D-0.040374
duration_ts=3D29700
duration=3D9.909910
= bit_rate=3D3
max_bit_rate=3DN/A
bits_per_raw_sample=3DN/A
nb_frame= s=3D1
nb_read_frames=3DN/A
nb_read_packets=3DN/A
DISPOSITION:defau= lt=3D1
DISPOSITION:dub=3D0
DISPOSITION:original=3D0
DISPOSITION:co= mment=3D0
DISPOSITION:lyrics=3D0
DISPOSITION:karaoke=3D0
DISPOSITI= ON:forced=3D0
DISPOSITION:hearing_impaired=3D0
DISPOSITION:visual_imp= aired=3D0
DISPOSITION:clean_effects=3D0
DISPOSITION:attached_pic=3D0<= br>TAG:creation_time=3D2010-05-25 22:47:06
TAG:language=3Deng
TAG:han= dler_name=3DApple Alias Data Handler
TAG:reel_name=3DDHC0034_1984.0040_p= master
TAG:timecode=3D00:30:40:13
[/STREAM]

[STREAM]
index= =3D0
codec_name=3Dv210
codec_long_name=3DUncompressed 4:2:2 10-bitprofile=3Dunknown
codec_type=3Dvideo
codec_time_base=3D1/2997
cod= ec_tag_string=3Dv210
codec_tag=3D0x30313276
width=3D720
height=3D4= 86
coded_width=3D720
coded_height=3D486
has_b_frames=3D0
sample= _aspect_ratio=3D0:1
display_aspect_ratio=3D0:1
pix_fmt=3Dyuv422p10le<= br>level=3D-99
color_range=3DN/A
color_space=3Dbt470bg
color_trans= fer=3Dunknown
color_primaries=3Dsmpte240m
chroma_location=3Dunspecifi= ed
timecode=3DN/A
refs=3D1
id=3DN/A
r_frame_rate=3D2997/100
= avg_frame_rate=3D893106/29921
time_base=3D1/2997
start_pts=3D-121
= start_time=3D-0.040374
duration_ts=3D29921
duration=3D9.983650
bit= _rate=3D222820111
max_bit_rate=3DN/A
bits_per_raw_sample=3D10
nb_f= rames=3D298
nb_read_frames=3DN/A
nb_read_packets=3DN/A
DISPOSITION= :default=3D1
DISPOSITION:dub=3D0
DISPOSITION:original=3D0
DISPOSIT= ION:comment=3D0
DISPOSITION:lyrics=3D0
DISPOSITION:karaoke=3D0
DIS= POSITION:forced=3D0
DISPOSITION:hearing_impaired=3D0
DISPOSITION:visu= al_impaired=3D0
DISPOSITION:clean_effects=3D0
DISPOSITION:attached_pi= c=3D0
TAG:creation_time=3D2010-05-25 22:47:06
TAG:language=3Deng
T= AG:handler_name=3DApple Alias Data Handler
TAG:encoder=3DUncompressed 10= bit
TAG:timecode=3D00:30:40:13
[/STREAM]
--001a11c2662025b8940527e86d2c-- From nobody Tue Dec 29 08:22:59 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA091A888E for ; Tue, 29 Dec 2015 08:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 cT6TmYibazoL for ; Tue, 29 Dec 2015 08:16:18 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67C21A888D for ; Tue, 29 Dec 2015 08:16:18 -0800 (PST) Received: by mail-ig0-x22e.google.com with SMTP id to4so164509876igc.0 for ; Tue, 29 Dec 2015 08:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=KMw89reXC1hMBsZ1QPSDRcruLRtCu52Gfw+seddcMGs=; b=rv+gsSeX0d7T+O4joIA5VIxMhX87UAs7ApApVjLJwcaXURl+YqKzANinFts9mB3xp9 QqLb/mmcVnLnk92y/bG30uXpODPlo6Qy0MA6nqo9wsBHIW5xtkQUTK+vFRlcM7qN07eI gUnM+MeufutSHIktOEFfTavGeESYLb4zNqITvCoERsXJGLE2EWHK5h8pvX4nG4BJiTDC AKyjnIi8ztPMvyq9IvxRIF3c2AWmRqcnFY0Xz5zJeAhpbPclNpSkX9IZrg392ol2FlAh UF3DDtQlak9k/lkjCytCF99eQPP4RGfZ/2Jp0EEtxLZXQAMShyk+XR4ejj9nr0DWtUfF g6lA== X-Received: by 10.50.29.110 with SMTP id j14mr59419824igh.87.1451405778062; Tue, 29 Dec 2015 08:16:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.5.79 with HTTP; Tue, 29 Dec 2015 08:15:38 -0800 (PST) From: Tessa Fallon Date: Tue, 29 Dec 2015 11:15:38 -0500 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=047d7bd6bca8d3944605280bbd17 Archived-At: X-Mailman-Approved-At: Tue, 29 Dec 2015 08:22:58 -0800 Subject: [Cellar] Matroksa/EBML and GitHub X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 16:16:20 -0000 --047d7bd6bca8d3944605280bbd17 Content-Type: text/plain; charset=UTF-8 Hi all, I've been approached by several people about the idea of moving this work as it relates to the IETF specifications to a GitHub repository to facilitate collaboration. If there is a group consensus that this would be productive, I'm happy to set it up. I would also like to ask if there might be any volunteers willing to administer the account on a day to day basis. We would need to agree on procedures for approving/evaluating pull requests and pushing changes before setting up the repository. Best, Tessa --047d7bd6bca8d3944605280bbd17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I've been approached by sev= eral people about the idea of moving this work as it relates to the IETF sp= ecifications to a GitHub repository to facilitate collaboration.=C2=A0 If t= here is a group consensus that this would be productive, I'm happy to s= et it up.=C2=A0 I would also like to ask if there might be any volunteers w= illing to administer the account on a day to day basis.=C2=A0 We would need= to agree on procedures for approving/evaluating pull requests and pushing = changes before setting up the repository.

Best,

Tessa
--047d7bd6bca8d3944605280bbd17-- From nobody Tue Dec 29 08:25:58 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9006B1A88AF for ; Tue, 29 Dec 2015 08:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 dG2zgVFAbKiy for ; Tue, 29 Dec 2015 08:25:53 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334A41A88B1 for ; Tue, 29 Dec 2015 08:25:51 -0800 (PST) Received: from maa2336d0.tmodns.net ([208.54.35.170]:58142 helo=[26.218.70.85]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aDx5p-000pwf-1I; Tue, 29 Dec 2015 11:25:50 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dave Rice X-Mailer: iPhone Mail (13A452) In-Reply-To: Date: Tue, 29 Dec 2015 11:25:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tessa Fallon X-OutGoing-Spam-Status: No, score=-1.0 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] Matroksa/EBML and GitHub X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 16:25:55 -0000 +1, especially for the components not already in GitHub. > On Dec 29, 2015, at 11:15 AM, Tessa Fallon wrote:= >=20 > Hi all, >=20 > I've been approached by several people about the idea of moving this work a= s it relates to the IETF specifications to a GitHub repository to facilitate= collaboration. If there is a group consensus that this would be productive= , I'm happy to set it up. I would also like to ask if there might be any vo= lunteers willing to administer the account on a day to day basis. We would n= eed to agree on procedures for approving/evaluating pull requests and pushin= g changes before setting up the repository. >=20 > Best, >=20 > Tessa > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Tue Dec 29 08:29:04 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F4C1A01A2 for ; Tue, 29 Dec 2015 08:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 y5jniaF0qwQn for ; Tue, 29 Dec 2015 08:29:01 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494561A0358 for ; Tue, 29 Dec 2015 08:29:01 -0800 (PST) Received: by mail-ig0-x22a.google.com with SMTP id to18so154873459igc.0 for ; Tue, 29 Dec 2015 08:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i1gVhpXCtdksw5es9b5gQoBsRcl+TAmAmRcFwR9ij0Q=; b=EZPZ5itNG2mA/thLapXBHvUKDv4lY3ralAzDiLvWGU0JbGY6lFwsvC56UBKEYO6diL Z8aQRex92vmAUT3EF5bv2M8qbAvRWjbGRwkOoyR4/yl+j3r8/JMYh38YBCCMHkGtYK8K ICRHybUuiuF3M7zRRZ7VCXACAi71Fao6qJCS/NEu0/8GPuhz7zWZrP2pMQ3kxGURZYX0 r4llp7qotuD21Nj0sjibphj9FMEuSjBP3Mg0cURC0lCwwI4KNUIZE8Cdx5aJF6WBbxSh Z+Dnen4Ah1sTd7NkuNqexNVMB95GAbz7KffAhpNdUtGX1zpTZAPo11P5qeZPyqAuUQlw hVHQ== MIME-Version: 1.0 X-Received: by 10.50.138.2 with SMTP id qm2mr35686231igb.91.1451406540715; Tue, 29 Dec 2015 08:29:00 -0800 (PST) Received: by 10.79.75.69 with HTTP; Tue, 29 Dec 2015 08:29:00 -0800 (PST) In-Reply-To: References: Date: Tue, 29 Dec 2015 11:29:00 -0500 Message-ID: From: Ashley Blewer To: Dave Rice Content-Type: multipart/alternative; boundary=001a1135ffb048be7205280bebdb Archived-At: Cc: Tessa Fallon , cellar@ietf.org Subject: Re: [Cellar] Matroksa/EBML and GitHub X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 16:29:03 -0000 --001a1135ffb048be7205280bebdb Content-Type: text/plain; charset=UTF-8 +1 as well. I'm also willing to act as one of the administrators for this site. I'm eager to show off what moving documentation to Github Pages would look like and start conversations around that! Ashley On Tue, Dec 29, 2015 at 11:25 AM, Dave Rice wrote: > +1, especially for the components not already in GitHub. > > > On Dec 29, 2015, at 11:15 AM, Tessa Fallon > wrote: > > > > Hi all, > > > > I've been approached by several people about the idea of moving this > work as it relates to the IETF specifications to a GitHub repository to > facilitate collaboration. If there is a group consensus that this would be > productive, I'm happy to set it up. I would also like to ask if there > might be any volunteers willing to administer the account on a day to day > basis. We would need to agree on procedures for approving/evaluating pull > requests and pushing changes before setting up the repository. > > > > Best, > > > > Tessa > > _______________________________________________ > > 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 > --001a1135ffb048be7205280bebdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 as well. I'm also willing to act as one of the admi= nistrators for this site.=C2=A0

I'm eager to show of= f what moving documentation to Github Pages would look like and start conve= rsations around that!

Ashley

On Tue, Dec 29, 2015 at 11:= 25 AM, Dave Rice <dave@dericed.com> wrote:
+1, especially for the components not already in GitHub.

> On Dec 29, 2015, at 11:15 AM, Tessa Fallon <tessa.fallon@gmail.com> wrote:
>
> Hi all,
>
> I've been approached by several people about the idea of moving th= is work as it relates to the IETF specifications to a GitHub repository to = facilitate collaboration.=C2=A0 If there is a group consensus that this wou= ld be productive, I'm happy to set it up.=C2=A0 I would also like to as= k if there might be any volunteers willing to administer the account on a d= ay to day basis.=C2=A0 We would need to agree on procedures for approving/e= valuating pull requests and pushing changes before setting up the repositor= y.
>
> Best,
>
> Tessa
> _______________________________________________
> 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

--001a1135ffb048be7205280bebdb-- From nobody Tue Dec 29 08:45:37 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4366E1A0233 for ; Tue, 29 Dec 2015 08:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.113 X-Spam-Level: X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 D4-MiTouuaz4 for ; Tue, 29 Dec 2015 08:45:35 -0800 (PST) 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 D208F1A0231 for ; Tue, 29 Dec 2015 08:45:34 -0800 (PST) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id A8AE348DF60 for ; Tue, 29 Dec 2015 17:45:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2015100101; t=1451407532; bh=xWc6qdRv7KubyDY9YJASpl1oIT8n94L7H+2jEX/+VHs=; h=Date:From:To:Subject:References:In-Reply-To; b=fXq5/wUFblPXZzUjXIqJHhogbMxdICt3qPBTCrjHwfWN0zOUmaNhGGj+7naZaX0th Z2Ixc7dnU7LrHpqQ894EJizigoGYBuCOm2TTaFSekwOlZixIeEkGHJ8NdSwD1Xtrbd GyEYMczybqv14dr9U7xw9VuvpJDpLbaZwkOTKTZvyOiHYIwt0VoM6F4OqgWfID8b6P NEpX7dW/GoDOD89gDPI3/ajavR279zO5b364DufIT187ftSZ9YlHe6KTNCYNyF0BXL WdGCRkGRMVHmSviLfZgGsIxmn/q9Q9u0RohjDSk7OvbW5mX0sMRmZxD9VdhuJmneub Re1om4/R0tKmPKTkZsdEuymydKKXlXup+0Fy0g+VZ5jYHUmL5I31Dt5ESChlbIrtta 0HzSeY7FMY+0kzAkdIChEW/FUb6v4B7oyPSGG9meimrI3LoZkI+hkPfPCsZziBlpQ7 9cb2N0RxKArdpR3Xo32D90ycUWckYIaFoetLGZq2N9njWgO7Ff3uv1PUS+9j9ndwkQ tSJ8wO0svV8A55MgkNu5SnlMShUCY6uktX7Miw+sP/ORS7uM7tkuLMccted7BZMDld lFydEmXGxEmDQiWWcf10qgIcQ0+4Ky38kXTosXgCYXalQH120kL/VghGADhw6zlAY/ SjI4oSwzKD5fOitb5IWluEwo= Received: by sweet-chili.local (Postfix, from userid 1000) id E947952A850; Tue, 29 Dec 2015 17:44:15 +0100 (CET) Date: Tue, 29 Dec 2015 17:44:15 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20151229164415.GH3494@bunkus.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oXNgvKVxGWJ0RPMJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] Matroksa/EBML and GitHub X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 16:45:36 -0000 --oXNgvKVxGWJ0RPMJ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, I'm all for it, and I'm also volunteering for the admin job. I'm already doing that for the current EBML RFC work anyway. As for the account: there is the Matroska organization account on Github[1] where the current work on creating the EBML RFC is taking place. Currently Steve Lhomme and myself have admin privileges for that organization. As your subject only talks about Matroska and EBML I'd consider the Matroska-Org account to be a possible if not the most appropriate place to host those sub-projects, and I'd welcome making more people admins and granting push privileges to others. If, however, your scope is somewhat wider and encompasses e.g. FFVW1 then I'm not so sure about that. You've explicitly mentioned creating a new account. What are your thoughts regarding the existing Matroska-Org account =E2=80=93 anything spe= cific against using it? Thanks. [1] https://github.com/Matroska-Org Kind regards, mosu --oXNgvKVxGWJ0RPMJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWgrhZAAoJEHSvAK3y4yyFjBkQALpyoZs2mCWCPC9Qi/meKpY7 0+YvUYJw5Z6PPUXZXP1Rz45Q9dcHpdbGi+CBcXpWmrl7f4+98I5ReCu9v2fZ48wY v5jswZtMhYr62s30/qg3nxyBXRcKhyrSqiW7Udjxh2ZSqujHC8dR/B1E6g1Tpbqj yQdY9s7NUOVj2lCoU+bL1cniWPZGghGVL5P9Ys4EOcMbVQRm7FKoidrGknUVWCfF 7KrOKPLYjbaxkxBPGO1b7K29geIJ8WqsyOwogAL+L9YXkSc8Qr95FjTB1QYaXa3Z ZCOVBXWB7iz5jokcXA9XxklsynzexOs8awVcdfP6YPrtUYzVVgaViVMyDu/rDmSr jmfnCqqnzETlKT/1izC2ObFc+lXquz0DLAAgjnce1l/TxaUku4PbNg0xXCToOOui P26aBWlRPSV8l7HnUTJkzgv6zmxKN5iBbYGBz3hFH0qErTe/XJu99wcTOr7I4LmE C0Tf6ueelwp4/503O8uvDvexrr/Uz9+kpyugCrs1QMHoxwQxQjGV12j7qCYw9Qnu qktO1wJJZLsiaigHtAGPuWUn9ecapikhBjwaG23SvPMEiwg9dsV0Xcd7Xt37YlH/ e+SDkYYJfKKaPwUAN6aZiySo9kXTzQY/VrNZPy5soiGpXvuzzUTfEV7hTVZ3a0XQ 6foayjKX6aba1vmqvk6Y =lSun -----END PGP SIGNATURE----- --oXNgvKVxGWJ0RPMJ-- From nobody Tue Dec 29 09:03:04 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69F51A88AE for ; Tue, 29 Dec 2015 09:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 JXn12sI0FyrB for ; Tue, 29 Dec 2015 09:03:01 -0800 (PST) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EC51A88AB for ; Tue, 29 Dec 2015 09:02:53 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 09E06C1930 for ; Tue, 29 Dec 2015 17:02:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygWZM7Nfkqs0 for ; Tue, 29 Dec 2015 17:02:52 +0000 (UTC) Received: from [10.0.0.42] (c-24-63-237-33.hsd1.ct.comcast.net [24.63.237.33]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 8C33ABFF15 for ; Tue, 29 Dec 2015 17:02:52 +0000 (UTC) Message-ID: <5682BCBB.4050102@xiph.org> Date: Tue, 29 Dec 2015 09:02:51 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Matroksa/EBML and GitHub X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 17:03:03 -0000 Tessa Fallon wrote: > to day basis. We would need to agree on procedures for > approving/evaluating pull requests and pushing changes before setting up > the repository. Since a number of people here may be new to the IETF... the normal procedure for individual drafts is "author discretion". I.e., this should be managed directly by the document editors. However, once a draft is formally adopted by the working group it is meant to reflect working group consensus, as per RFC 7221. In practice that looks a lot like "author discretion", though there are important differences (see Section 1.2, Working Group Authority and Consensus). I.e., the working group places a lot of trust in the document editors. Currently we have no drafts that have been formally adopted as working group drafts. It is possible to grant commit access on Github more broadly than to just the official document editors, but then it becomes the editors' responsibility to ensure the document accurately reflects WG consensus before publishing a new version at the IETF. I think we can leave that decision up to the individual editors, once we have some. I.e., we can let the document editors choose whom they wish to trust. With Github there is a danger that substantive discussion moves away from the mailing list (where it is subject to the IETF Note Well and other rules), and onto individual pull requests and Github issues, which can make the presence of working group consensus less clear. I would encourage people to keep substantive discussion on the mailing list. If you see discussions that are more than merely administrative, please send a message to the list about them. From nobody Tue Dec 29 09:28:14 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCAB1A0130 for ; Tue, 29 Dec 2015 09:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 ylgch6unHla5 for ; Tue, 29 Dec 2015 09:28:08 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676D01A0126 for ; Tue, 29 Dec 2015 09:28:08 -0800 (PST) Received: from maa2336d0.tmodns.net ([208.54.35.170]:62418 helo=[26.218.70.85]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aDy41-002LXR-Vs; Tue, 29 Dec 2015 12:28:06 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dave Rice X-Mailer: iPhone Mail (13A452) In-Reply-To: <5682BCBB.4050102@xiph.org> Date: Tue, 29 Dec 2015 12:27:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7FB201B3-0F03-42C3-A70D-ADE885AD2908@dericed.com> References: <5682BCBB.4050102@xiph.org> To: "Timothy B. Terriberry" X-OutGoing-Spam-Status: No, score=-1.0 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] Matroksa/EBML and GitHub X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 17:28:13 -0000 Hi, > On Dec 29, 2015, at 12:02 PM, Timothy B. Terriberry wr= ote: >=20 > Tessa Fallon wrote: >> to day basis. We would need to agree on procedures for >> approving/evaluating pull requests and pushing changes before setting up >> the repository. >=20 > Since a number of people here may be new to the IETF... the normal procedu= re for individual drafts is "author discretion". I.e., this should be manage= d directly by the document editors. However, once a draft is formally adopte= d by the working group it is meant to reflect working group consensus, as pe= r RFC 7221. In practice that looks a lot like "author discretion", though th= ere are important differences (see Section 1.2, Working Group Authority and C= onsensus). I.e., the working group places a lot of trust in the document edi= tors. Currently we have no drafts that have been formally adopted as working= group drafts. We have many works in progress for EBML, Matroska, FFV1 and FLAC. These are= currently in GitHub repos, Drupal, or websites. At what point should they b= ecome 'working group drafts'? Is there a particular threshold in the work on= these underlying documents to cross in order to be a working group draft? > It is possible to grant commit access on Github more broadly than to just t= he official document editors, but then it becomes the editors' responsibilit= y to ensure the document accurately reflects WG consensus before publishing a= new version at the IETF. I think we can leave that decision up to the indiv= idual editors, once we have some. I.e., we can let the document editors choo= se whom they wish to trust. >=20 > With Github there is a danger that substantive discussion moves away from t= he mailing list (where it is subject to the IETF Note Well and other rules),= and onto individual pull requests and Github issues, which can make the pre= sence of working group consensus less clear. I think this has been the case although I've made some reports back to the l= ist to summarize changes. However I can switch to a FFmpeg style of patching= and send patches to this list for review (rather than github pull requests)= and the document editor can manage their application. > I would encourage people to keep substantive discussion on the mailing lis= t. If you see discussions that are more than merely administrative, please s= end a message to the list about them. +1 Dave Rice From nobody Tue Dec 29 10:48:27 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7841A037A for ; Tue, 29 Dec 2015 10:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 uLbPc2bB2kky for ; Tue, 29 Dec 2015 10:48:22 -0800 (PST) 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 258C31A0379 for ; Tue, 29 Dec 2015 10:48:21 -0800 (PST) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBTImIWS008208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 29 Dec 2015 19:48:19 +0100 Received: from [192.168.1.2] (85-218-38-132.dclient.lsne.ch [85.218.38.132]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBTImIuD004092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Dec 2015 19:48:18 +0100 From: Reto Kromer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <61A5D254-C509-4AEC-B7D0-EF0941F36193@reto.ch> Date: Tue, 29 Dec 2015 19:48:18 +0100 References: <5682BCBB.4050102@xiph.org> <7FB201B3-0F03-42C3-A70D-ADE885AD2908@dericed.com> In-Reply-To: <7FB201B3-0F03-42C3-A70D-ADE885AD2908@dericed.com> To: cellar@ietf.org X-Mailer: iPhone Mail (13C75) 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] Matroksa/EBML and GitHub X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 18:48:26 -0000 +1 Best regards, Reto > On 29.12.2015, at 18:27, Dave Rice wrote: >=20 > Hi, >=20 >> On Dec 29, 2015, at 12:02 PM, Timothy B. Terriberry w= rote: >>=20 >> Tessa Fallon wrote: >>> to day basis. We would need to agree on procedures for >>> approving/evaluating pull requests and pushing changes before setting up= >>> the repository. >>=20 >> Since a number of people here may be new to the IETF... the normal proced= ure for individual drafts is "author discretion". I.e., this should be manag= ed directly by the document editors. However, once a draft is formally adopt= ed by the working group it is meant to reflect working group consensus, as p= er RFC 7221. In practice that looks a lot like "author discretion", though t= here are important differences (see Section 1.2, Working Group Authority and= Consensus). I.e., the working group places a lot of trust in the document e= ditors. Currently we have no drafts that have been formally adopted as worki= ng group drafts. >=20 > We have many works in progress for EBML, Matroska, FFV1 and FLAC. These a= re currently in GitHub repos, Drupal, or websites. At what point should they= become 'working group drafts'? Is there a particular threshold in the work o= n these underlying documents to cross in order to be a working group draft? >=20 >> It is possible to grant commit access on Github more broadly than to just= the official document editors, but then it becomes the editors' responsibil= ity to ensure the document accurately reflects WG consensus before publishin= g a new version at the IETF. I think we can leave that decision up to the in= dividual editors, once we have some. I.e., we can let the document editors c= hoose whom they wish to trust. >>=20 >> With Github there is a danger that substantive discussion moves away from= the mailing list (where it is subject to the IETF Note Well and other rules= ), and onto individual pull requests and Github issues, which can make the p= resence of working group consensus less clear. >=20 > I think this has been the case although I've made some reports back to the= list to summarize changes. However I can switch to a FFmpeg style of patchi= ng and send patches to this list for review (rather than github pull request= s) and the document editor can manage their application. >=20 >> I would encourage people to keep substantive discussion on the mailing li= st. If you see discussions that are more than merely administrative, please s= end a message to the list about them. >=20 > +1 >=20 > Dave Rice >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Tue Dec 29 12:55:32 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EFB1A897E for ; Tue, 29 Dec 2015 12:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 JDg-xdS22k1Y for ; Tue, 29 Dec 2015 12:55:29 -0800 (PST) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC831A897C for ; Tue, 29 Dec 2015 12:55:29 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id BE5A3C0710 for ; Tue, 29 Dec 2015 20:55:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAGkeMOAeJDO for ; Tue, 29 Dec 2015 20:55:28 +0000 (UTC) Received: from [10.0.0.42] (c-24-63-237-33.hsd1.ct.comcast.net [24.63.237.33]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 50515BFF12 for ; Tue, 29 Dec 2015 20:55:28 +0000 (UTC) Message-ID: <5682F33F.7040207@xiph.org> Date: Tue, 29 Dec 2015 12:55:27 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: <5682BCBB.4050102@xiph.org> <7FB201B3-0F03-42C3-A70D-ADE885AD2908@dericed.com> In-Reply-To: <7FB201B3-0F03-42C3-A70D-ADE885AD2908@dericed.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Matroksa/EBML and GitHub X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 20:55:31 -0000 Dave Rice wrote: > We have many works in progress for EBML, Matroska, FFV1 and FLAC. > These are currently in GitHub repos, Drupal, or websites. At what > point should they become 'working group drafts'? Is there a > particular threshold in the work on these underlying documents to > cross in order to be a working group draft? An excellent question. RFC 7221 documents the criteria that are generally considered for adoption of a draft by a WG: https://tools.ietf.org/html/rfc7221#section-2.2 Since we are not likely to see competing approaches for our various milestones, and the milestones themselves are pretty clear, I would say that for this group the two important questions are 1) "Does the document provide an acceptable platform for continued effort by the working group?" and 2) "Is the draft likely to be completed in a timely manner?" For example, a largely complete first draft (a few TODOs or missing sections would be fine, of course) with one or two clearly active authors would be a good basis to answer both of those questions in the affirmative. From a procedural point of view, the draft would have to be submitted to https://datatracker.ietf.org/submit/ in the usual I-D format. The actual source for the draft can continue to live in Github, or whatever is convenient. Once submitted, the chairs (Tessa and I) can issue a call for adoption, and if there is rough consensus, we will appoint editors and formally adopt the draft. From nobody Tue Dec 29 14:28:04 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C6B1A8A87 for ; Tue, 29 Dec 2015 14:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 k56vaFaWsJ8n for ; Tue, 29 Dec 2015 14:28:02 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 373A51A8A86 for ; Tue, 29 Dec 2015 14:28:02 -0800 (PST) Received: by mail-pa0-x235.google.com with SMTP id yy13so37131262pab.3 for ; Tue, 29 Dec 2015 14:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=5u8bC5KGc29tpI2tMLN0RN6Kp7fZ4nv0w9xGx3noYGo=; b=LlkCBbPrbS7r9gl2R9eThMojxJZLP3nmTxFIVIh3OYGssudBRZ467bJS/XbWwAfri4 ZrLzEOsI9FOPZ0umE/zsgnWNCWx1NHY2yBEU+i2BzKlOS+sXHOv0Rks4LhpqN0QTIobG Ez0I8BBp2FMHnCoWK+mp8w8vLqfxA/1Mi5Y/l+9UuWY6m5afcltkiovsG3o5m7gQBbyX yFo8/lJEdFJYDRDkCUajIN1/zEOuA9xhmFwYAbwmayaBaInJwjpautYn1lYnyv8zq0dJ jW/7Tvs7cmhrhDPP1OeDYQ06HsxKYmEBljGOCbynfGU8uKBB+0qqBhir7x82v0Q5m7GE VBkg== 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 :content-type; bh=5u8bC5KGc29tpI2tMLN0RN6Kp7fZ4nv0w9xGx3noYGo=; b=COQ1dhug9S2U93IWyTeKeJoIbivjqRl5sniR/JBrD0dFobr9EZVYgpmdXfXgNvogj7 +iKHILzyGh0mxJ6FlIQjP3fNlIEguSJ304RdiFtwgrhzL0tEJPD0CXFBYz+lDXtaidfv lxDPWBOl+TZih/wLAzBdBapclHEuCyGDC/EWXAK4aUKMN/R/p3aqm0Pd6obtLTBUBIEs xWeF3Gb5RUsNiKJ6Ua/LY2rOKjgg7hhMe49b2aEuWTiZF7wYTLlA+jBBPuQIj/AW0xqC yZe3Fd+el5ruJ2sjxMJr4pWntv7b/RL5W/KemIs/h2QjWL/3+1zs/Uw+F4MylOevxmiw Dnuw== X-Gm-Message-State: ALoCoQndTLqNFuDsZjbGsZ9rFQC+Fqpuvq6oY5/6lzrPRJKxJlpACrjLaWCXnOVjllUBQuVEtoY93Za0XIR8um7ScetHNoO+mXkoFhMAu7d/9SJdHBSz9EY= X-Received: by 10.66.192.7 with SMTP id hc7mr89267523pac.48.1451428081680; Tue, 29 Dec 2015 14:28:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.156.165 with HTTP; Tue, 29 Dec 2015 14:27:42 -0800 (PST) From: Michael Bradshaw Date: Tue, 29 Dec 2015 14:27:42 -0800 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=047d7bdcac443a1580052810ef65 Archived-At: Subject: [Cellar] On the multiplicity of Info elements X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 22:28:03 -0000 --047d7bdcac443a1580052810ef65 Content-Type: text/plain; charset=UTF-8 Info elements may be repeated within a Segment since it is marked as "mult." Is this correct, and does it make sense? It seems to me like there should be one Info element within a Segment. I'm actually not really sure how to sanely handle two Info elements within the same Segment. --Michael --047d7bdcac443a1580052810ef65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Info elements may be repeated within a Segment since it is= marked as "mult."

Is this correct, and does i= t make sense? It seems to me like there should be one Info element within a= Segment. I'm actually not really sure how to sanely handle two Info el= ements within the same Segment.

--Michael
--047d7bdcac443a1580052810ef65-- From nobody Tue Dec 29 14:39:22 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819741A8A93 for ; Tue, 29 Dec 2015 14:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 4Q9Xk0q9nGCO for ; Tue, 29 Dec 2015 14:39:18 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830081A8A90 for ; Tue, 29 Dec 2015 14:39:18 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:34394 helo=[10.0.1.65]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aE2vD-001CnO-Kq for cellar@ietf.org; Tue, 29 Dec 2015 17:39:18 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_343AE034-D7EE-4E79-B0B8-E5CC447984F7" Message-Id: Date: Tue, 29 Dec 2015 17:39:36 -0500 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) X-OutGoing-Spam-Status: No, score=-1.0 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] EBML Draft TODOs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 22:39:20 -0000 --Apple-Mail=_343AE034-D7EE-4E79-B0B8-E5CC447984F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I'm replying to Tim's email = = as a new thread, specifically about EBML Draft to-dos. I propose that = the EBML specification, currently at stored in a GitHub repo = be considered as a working group draft. The document is = largely complete and well discussed. For remaining TODOs, I suggest this. Please add others if needed. - Refine the definition of EBML Schema The current documentation of EBML Schema is based upon = Matroska's specdata.xml file. However there is much agreement that the = EBML Schema definition be expanded for greater machine-readability and = expression of restrictions (adopting many ideas from the spec for XML = Schema). This effort would ideally benefits Matroska-format validators = in both the Matroska and webM communities as well as any other usage of = the EBML format. - Clarity on the use of custom data types The EBML spec defines a short list of data types but doesn't = state if the data types are restricted to the list or if an EBML Element = may be defined to a custom data type (as is permitted in XML). - Custom elements in EBML Header There is some open debate on whether or not a valid EBML = Document may contain elements within the EBML Header that are not = defined in the EBML specification.=20 - Clarity on CRC Definition There are several competing specs on the EBML CRC Element as = discussed on GitHub = . The work = here should resolve the confusion there. - EBML Header does not self-define There was some discussion that led to an understanding that the = EBML Header defines qualities about the corresponding EBML Body but not = the EBML Header itself. Thus a MaxIDLength could be 2 even though the = EBML Header has uses IDLengths of 4. The outcome of this discussion = needs to be incorporated into the EBML Draft. - Security Considerations RFC docs seem to require a section on security. Moritz began to = list issues here = but there is nothing drafted for the spec yet. I think that's about it for to do's. Please/edit/comment add if I'm = missing anything. Dave Rice= --Apple-Mail=_343AE034-D7EE-4E79-B0B8-E5CC447984F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,

I'm= replying to Tim's email as a new thread, specifically about = EBML Draft to-dos. I propose that the EBML specification, currently at = stored in a GitHub repo be considered as a = working group draft. The document is largely complete and well = discussed.

For = remaining TODOs, I suggest this. Please add others if needed.

- Refine the definition = of EBML Schema
The current documentation of EBML = Schema is based upon Matroska's specdata.xml file. However there is much = agreement that the EBML Schema definition be expanded for greater = machine-readability and expression of restrictions (adopting many ideas = from the spec for XML Schema). This effort would ideally benefits = Matroska-format validators in both the Matroska and webM communities as = well as any other usage of the EBML format.

- Clarity on the use of custom data = types
The EBML spec defines a short = list of data types but doesn't state if the data types are restricted to = the list or if an EBML Element may be defined to a custom data type (as = is permitted in XML).

- Custom elements in EBML Header
There is = some open debate on whether or not a valid EBML Document may contain = elements within the EBML Header that are not defined in the EBML = specification. 

- Clarity on CRC Definition
There are = several competing specs on the EBML CRC Element as discussed on GitHub. The work here should resolve the = confusion there.

- EBML Header does not self-define
There was = some discussion that led to an understanding that the EBML Header = defines qualities about the corresponding EBML Body but not the EBML = Header itself. Thus a MaxIDLength could be 2 even though the EBML Header = has uses IDLengths of 4. The outcome of this discussion needs to be = incorporated into the EBML Draft.

- Security Considerations
= RFC docs seem to require a section on security. Moritz began to = list issues here but there is nothing drafted = for the spec yet.

I think that's about it for to do's. Please/edit/comment add = if I'm missing anything.

Dave Rice
= --Apple-Mail=_343AE034-D7EE-4E79-B0B8-E5CC447984F7-- From nobody Tue Dec 29 15:01:43 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E6E1A8AA9 for ; Tue, 29 Dec 2015 15:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 2bvIbGKXb-WA for ; Tue, 29 Dec 2015 15:01:40 -0800 (PST) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42ABB1A8AA6 for ; Tue, 29 Dec 2015 15:01:40 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 8FCFAC02A6 for ; Tue, 29 Dec 2015 23:01:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBt5AJLyeBLq for ; Tue, 29 Dec 2015 23:01:39 +0000 (UTC) Received: from [10.0.0.42] (c-24-63-237-33.hsd1.ct.comcast.net [24.63.237.33]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 3BAB6C017A for ; Tue, 29 Dec 2015 23:01:39 +0000 (UTC) Message-ID: <568310D2.7060702@xiph.org> Date: Tue, 29 Dec 2015 15:01:38 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] EBML Draft TODOs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 23:01:42 -0000 Dave Rice wrote: > I think that's about it for to do's. Please/edit/comment add if I'm > missing anything. Well, the big one (for me as chair) would be the submission of an individual I-D to the datatracker to adopt. Since you're starting from Markdown, pandoc2rfc might be suitable (see RFC 7328), but I've never used it personally. From nobody Tue Dec 29 15:46:50 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8861A8AEB for ; Tue, 29 Dec 2015 15:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 FfiWFqxSF4Yk for ; Tue, 29 Dec 2015 15:46:44 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5FB1A8AEA for ; Tue, 29 Dec 2015 15:46:44 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:43593 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aE3yT-002m5Q-DM for cellar@ietf.org; Tue, 29 Dec 2015 18:46:44 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_98A91BE5-1AD9-4794-9D3A-52DA1CA61304" Message-Id: <331C4986-F55D-4CEC-A010-89BBDEF5FAC2@dericed.com> Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Date: Tue, 29 Dec 2015 18:46:39 -0500 References: To: cellar@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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] EBML Draft TODOs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 23:46:47 -0000 --Apple-Mail=_98A91BE5-1AD9-4794-9D3A-52DA1CA61304 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On Dec 29, 2015, at 5:39 PM, Dave Rice wrote: [=E2=80=A6] > I'm replying to Tim's email = = as a new thread, specifically about EBML Draft to-dos. I propose that = the EBML specification, currently at stored in a GitHub repo = be considered as a working group draft. The document is = largely complete and well discussed. >=20 > For remaining TODOs, I suggest this. Please add others if needed. >=20 > - Refine the definition of EBML Schema > The current documentation of EBML Schema is based upon = Matroska's specdata.xml file. However there is much agreement that the = EBML Schema definition be expanded for greater machine-readability and = expression of restrictions (adopting many ideas from the spec for XML = Schema). This effort would ideally benefits Matroska-format validators = in both the Matroska and webM communities as well as any other usage of = the EBML format. I=E2=80=99ll send patches on this in a separate thread over the next = week. > - Clarity on the use of custom data types > The EBML spec defines a short list of data types but doesn't = state if the data types are restricted to the list or if an EBML Element = may be defined to a custom data type (as is permitted in XML). AFAIK webM and Matroska only use the data types as already defined in = the EBML specification. With the addition of restrictions in element = definitions (as planned in work on EBML Schema) the need for custom data = types is reduced. I propose to limit the spec to the current data types = and in the EBML Element Types = section to change: "Each defined EBML Element MUST have a declared Element Type.=E2=80=9D to "Each defined EBML Element MUST declared one of the following Element = Types.=E2=80=9D There also needs to be some clean-up on whether to use the term = =E2=80=9CElement Type=E2=80=9D or =E2=80=9CData Type=E2=80=9D. Any = preference? > - Custom elements in EBML Header > There is some open debate on whether or not a valid EBML = Document may contain elements within the EBML Header that are not = defined in the EBML specification.=20 Actually this point seems to have already been settled and the section = on the EBML Header = states that the "EBML Header MUST ONLY contain = EBML Elements that are defined as part of the EBML Specification=E2=80=9D.= > - Clarity on CRC Definition > There are several competing specs on the EBML CRC Element as = discussed on GitHub = . The work = here should resolve the confusion there. This issue is complex so I=E2=80=99ll start a new thread. > - EBML Header does not self-define > There was some discussion that led to an understanding that the = EBML Header defines qualities about the corresponding EBML Body but not = the EBML Header itself. Thus a MaxIDLength could be 2 even though the = EBML Header has uses IDLengths of 4. The outcome of this discussion = needs to be incorporated into the EBML Draft. This issue is also resolved as the definitions of EBMLMaxIDLength and = EBMLMaxSizeLength already clarify that they define the elements of the = EBML Body. Since the Header doesn=E2=80=99t self-define size and id = limits, the spec now clarifies them as "All EBML Elements within the = EBML Header MUST NOT utilize any Element ID with a length greater than 4 = octets. All EBML Elements within the EBML Header MUST NOT utilize any = Element Data Size with a length greater than 4 octets." > - Security Considerations > RFC docs seem to require a section on security. Moritz began to = list issues here = but there is nothing drafted for the spec yet. Tim, is a =E2=80=9CSecurity=E2=80=9D section required? > I think that's about it for to do's. Please/edit/comment add if I'm = missing anything. Dave Rice --Apple-Mail=_98A91BE5-1AD9-4794-9D3A-52DA1CA61304 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On Dec 29, 2015, at 5:39 PM, = Dave Rice <dave@dericed.com> wrote:

[=E2=80=A6]

I'm replying to = Tim's email as a new thread, specifically about = EBML Draft to-dos. I propose that the EBML specification, currently at = stored in a GitHub repo be considered as a = working group draft. The document is largely complete and well = discussed.

For = remaining TODOs, I suggest this. Please add others if needed.

- Refine the definition = of EBML Schema
The current documentation of EBML = Schema is based upon Matroska's specdata.xml file. However there is much = agreement that the EBML Schema definition be expanded for greater = machine-readability and expression of restrictions (adopting many ideas = from the spec for XML Schema). This effort would ideally benefits = Matroska-format validators in both the Matroska and webM communities as = well as any other usage of the EBML = format.

I=E2=80=99ll send patches on this in a separate = thread over the next week.

- Clarity on the use of custom data = types
The EBML spec defines a short = list of data types but doesn't state if the data types are restricted to = the list or if an EBML Element may be defined to a custom data type (as = is permitted in XML).

AFAIK webM and Matroska only use the data types as = already defined in the EBML specification. With the addition of = restrictions in element definitions (as planned in work on EBML Schema) = the need for custom data types is reduced. I propose to limit the spec = to the current data types and in the EBML Element = Types section to change:

"Each defined EBML Element MUST have a declared = Element Type.=E2=80=9D

to

"Each = defined EBML Element MUST declared one of the following Element = Types.=E2=80=9D

There also needs to = be some clean-up on whether to use the term =E2=80=9CElement Type=E2=80=9D= or =E2=80=9CData Type=E2=80=9D. Any preference?

- = Custom elements in EBML Header
There is = some open debate on whether or not a valid EBML Document may contain = elements within the EBML Header that are not defined in the EBML = specification. 

Actually this point seems to have already been = settled and the section on the EBML = Header states that the "EBML Header MUST ONLY contain EBML = Elements that are defined as part of the EBML Specification=E2=80=9D.
- = Clarity on CRC Definition
There are = several competing specs on the EBML CRC Element as discussed on GitHub. The work here should resolve the = confusion there.

This issue is complex so I=E2=80=99ll start a new = thread.

- EBML Header does not self-define
= There was some discussion that led to an understanding that the = EBML Header defines qualities about the corresponding EBML Body but not = the EBML Header itself. Thus a MaxIDLength could be 2 even though the = EBML Header has uses IDLengths of 4. The outcome of this discussion = needs to be incorporated into the EBML = Draft.

This = issue is also resolved as the definitions of EBMLMaxIDLength and = EBMLMaxSizeLength already clarify that they define the elements of the = EBML Body. Since the Header doesn=E2=80=99t self-define size and id = limits, the spec now clarifies them as "All EBML Elements within the = EBML Header MUST NOT utilize any Element ID with a length greater = than 4 octets. All EBML Elements within the EBML Header MUST NOT = utilize any Element Data Size with a length greater than 4 = octets."

- Security Considerations
RFC docs = seem to require a section on security. Moritz began to list = issues here but there is nothing drafted = for the spec yet.

Tim, is a =E2=80=9CSecurity=E2=80=9D section = required?

I think that's about it for to do's. Please/edit/comment add = if I'm missing anything.

Dave Rice

= --Apple-Mail=_98A91BE5-1AD9-4794-9D3A-52DA1CA61304-- From nobody Tue Dec 29 16:10:24 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781831A8BC0 for ; Tue, 29 Dec 2015 16:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 MncF_VTBXW4o for ; Tue, 29 Dec 2015 16:10:20 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD521A8BBF for ; Tue, 29 Dec 2015 16:10:20 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:47942 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aE4LJ-003SNU-Ki for cellar@ietf.org; Tue, 29 Dec 2015 19:10:19 -0500 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <99AE1BC4-B7DC-492A-BD79-A24B4012A20A@dericed.com> Date: Tue, 29 Dec 2015 19:10:15 -0500 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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] clarity for the EBML CRC Element X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 00:10:21 -0000 The EBML CRC Element has many contradictory definitions. Version 1: The Matroska draft states: "The CRC is computed on all the data of the Master element it's in. The = CRC element should be the first in it's parent master for easier = reading. All level 1 elements should include a CRC-32. The CRC in use is = the IEEE CRC32 Little Endian" Version 2: An older Matroska draft at = http://matroska.org/technical/specs/rfc/index.html states: "The CRC32 container can be placed around any EBML element or elements. = The value stored in CRC32Value is the result of the CRC-32 [CRC32] = checksum performed on the other child elements. CRC32 :=3D c3 container [ level:1..; card:*; ] { %children; CRC32Value :=3D 42fe binary [ size:4; ] }=E2=80=9D Version 3: The EBML draft states: "The CRC is computed on all the data from the last CRC element (or start = of the upper level element), up to the CRC element, including other = previous CRC elements. All level 1 elements SHOULD include a CRC-32." Issue with Version 1: Usually the Matroska version is considered authoritative since that = documentation was the most maintained; however, in this case the = Matroska definition doesn=E2=80=99t make sense as it implies that the = CRC Element is documenting a CRC value of data that includes the CRC = Element itself. Issue with Version 2: This definition refers the CRC Element as a Master-element (aka = =E2=80=9Ccontainer=E2=80=9D) with a sub-element (called =E2=80=9CCRC32Valu= e" 0x42FE) that contains the hash. AFAIK there has never been such an = implementation. Additionally this draft does not have an open license. Issues with Version 3: I think there is a typo and that: "All level 1 elements SHOULD include a = CRC-32=E2=80=9D should be "All level 1 Master-elements SHOULD include a = child CRC Element.=E2=80=9D The procedure for using multiple CRC Elements within a single = Master-element seems very inefficient with each subsequent CRC = representing the data of all prior CRC Elements within the same Parent = Element. This is like a rolling checksum although I=E2=80=99m not sure = that is what was intended. Also the definition implies that the CRC element can occur multiple = times within the parent element while the definition in both EBML and = Matroska clarifies that CRC is not a =E2=80=98multiple' element. So, can we clarify the following: - The CRC Element may only occur 0 or 1 times as a child element of a = Master-Element. - That the CRC Element is a binary element and not a Master-element - There is no definition for a CRC32Value element - Is there a placement requirement or suggestion for the use of the CRC = element within a parent (i.e. "should be the first in it's parent = master=E2=80=9D) - What data exactly does the CRC value represent? All Element Data of the parent element (unfeasible)? The entire Parent Element (including the parent=E2=80=99s = Element ID, Element Data Size, and Element Data) (also unfeasible)? All Element Data of the parent element excepting the child CRC = element? The entire Parent Element (including the parent=E2=80=99s = Element ID, Element Data Size, and Element Data) excepting the child CRC = element? All data from the beginning of the Master-element up to the = beginning of the CRC Element? All data from the beginning of the Master-element=E2=80=99s = Element Data up to the beginning of the CRC Element? I understand these clarifications have an impact on the validity of = existing EBML implementations, but I=E2=80=99ve rarely seen any = implementation of the EBML CRC element (better documentation may = encourage such implementations ;) Dave Rice= From nobody Tue Dec 29 16:28:35 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5D41A8F41 for ; Tue, 29 Dec 2015 16:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 KT9KEZcFukMi for ; Tue, 29 Dec 2015 16:28:33 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4FE1A8F3E for ; Tue, 29 Dec 2015 16:28:32 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:37699 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aE4cw-003r1y-Sv; Tue, 29 Dec 2015 19:28:32 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dave Rice In-Reply-To: Date: Tue, 29 Dec 2015 19:28:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Michael Bradshaw X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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] On the multiplicity of Info elements X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 00:28:33 -0000 > On Dec 29, 2015, at 5:27 PM, Michael Bradshaw = wrote: >=20 > Info elements may be repeated within a Segment since it is marked as = "mult." >=20 > Is this correct, and does it make sense? It seems to me like there = should be one Info element within a Segment. I'm actually not really = sure how to sanely handle two Info elements within the same Segment. Perhaps this is a bug in the documentation. I made a Matroska file with = two level 1 Info elements and VLC used the first one while FFmpeg used = the second one. I can=E2=80=99t see a use-case where more than one Info = element would be used as the child element of the same Segment element. SeekHead, Info, Cluster, Tracks, and Tags are multiple. And Cues, Attachments, and Chapters are non-multiple. ??? Dave Rice= From nobody Tue Dec 29 16:48:16 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60771A9024 for ; Tue, 29 Dec 2015 16:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 x6y6pAlewsxt for ; Tue, 29 Dec 2015 16:48:14 -0800 (PST) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF43A1A9022 for ; Tue, 29 Dec 2015 16:48:14 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 17C7DC2326 for ; Wed, 30 Dec 2015 00:48:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7_5ffDgTOyu for ; Wed, 30 Dec 2015 00:48:13 +0000 (UTC) Received: from [10.0.0.42] (c-24-63-237-33.hsd1.ct.comcast.net [24.63.237.33]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id A27C9C196B for ; Wed, 30 Dec 2015 00:48:13 +0000 (UTC) Message-ID: <568329CC.1030502@xiph.org> Date: Tue, 29 Dec 2015 16:48:12 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: <331C4986-F55D-4CEC-A010-89BBDEF5FAC2@dericed.com> In-Reply-To: <331C4986-F55D-4CEC-A010-89BBDEF5FAC2@dericed.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cellar] EBML Draft TODOs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 00:48:15 -0000 Dave Rice wrote: > Tim, is a “Security” section required? Yes. This requirement is spelled out in RFC 7332. See RFC 3552 for some guidelines on writing these sections, or RFC 6716 for an example of such a section for a codec and draft-ietf-codec-oggopus for an example of such a section for a container. From nobody Tue Dec 29 23:10:30 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9C31AC3BE for ; Tue, 29 Dec 2015 23:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 sm2ujTpJUPIC for ; Tue, 29 Dec 2015 23:10:27 -0800 (PST) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E811AC3BF for ; Tue, 29 Dec 2015 23:10:26 -0800 (PST) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBU79ct8025746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 30 Dec 2015 08:09:39 +0100 Received: from Castor.local (159.146.4.85.dynamic.wline.res.cust.swisscom.ch [85.4.146.159]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBU79bcf023333; Wed, 30 Dec 2015 08:09:38 +0100 Date: Wed, 30 Dec 2015 08:09:39 +0100 From: Reto Kromer To: Dave Rice X-Priority: 3 In-Reply-To: <331C4986-F55D-4CEC-A010-89BBDEF5FAC2@dericed.com> 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: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML Draft TODOs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 07:10:29 -0000 Dave Rice wrote: >Tim, is a =E2=80=9CSecurity=E2=80=9D section required? I'm not Tim, but yes, this is explicitly required. See RFC 7332: https://tools.ietf.org/html/rfc7332 Best regards, Reto AV Preservation by reto.ch chemin du Suchet 5 | 1024 Ecublens | Switzerland Web: http://reto.ch | Twitter: @retoch From nobody Wed Dec 30 01:19:39 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3BD1A1B71 for ; Wed, 30 Dec 2015 01:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.113 X-Spam-Level: X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 bgzUrfx3JU5O for ; Wed, 30 Dec 2015 01:19:37 -0800 (PST) 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 3A5241A1B69 for ; Wed, 30 Dec 2015 01:19:37 -0800 (PST) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 5663F4ECE28 for ; Wed, 30 Dec 2015 10:19:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2015100101; t=1451467173; bh=tGjit2LlsCl6EFTHodA4g3fVCVbqTA0yVh9k/6hr0Ek=; h=Date:From:To:Subject:References:In-Reply-To; b=DawGC7dwx79guAV4YfCqk5aBb8vQGCeyqEUrQzIDrn9n8O59LJppvW3qs3rPJxEhF Cs2vOmfK7sxpDb/c/ThJdC/oibs+gwz7M6j8LAboDAoUbs5cqV5k8N/gbCO7Bi5wFa udoCB6ibvFGW78nL0XiZ9TOwt+BKLwllyx2NQ2WOjtE8lCYi/btyBwPZO5rWs9ybSK XXSiuktavnUKFuEiprWbMSZGj1NV36wWexDToEHr3QS3kveVGTMw0+xnIMzaOFi41c MIvXbwzb1HwKTpTeMdX3dyZp0vx/Zgma3eA+rO0lUqH7t8G6cb8/aryRCRfCp4SBCA jDDRunqiB//nmD6LML5W0RtQ7MDjffcqMxTKXx7op73ZDGsXg6hx/zxbC3j/LP99OA CPGP5su8P2nN1OZjYBAZTpqgQipo8xRm4WvC6BjsKwSY7eGRACWJh9LG4TxMo6mC+o HnBvh/ORuAzGsJ92KcgUW3EAvpG1zFOwURpXtPljkagthlNV/f0doarSWTZN2YgFK8 fxGIgR9k5ZoyqxmVCjU5DAD9qCPS6yn+WOPT3wAvwCmlXcVvzjoE5wQHyNgP5k2j13 yqTj4VREUGF0zugyIR9hMZGnM2kLcQhwaHPCJQQcEls6u0HW5/wp1JmHPis6qB0ubb hjUU/zq5+Jq81Z4wvyWKoHpA= Received: by sweet-chili.local (Postfix, from userid 1000) id 40520555F90; Wed, 30 Dec 2015 10:18:12 +0100 (CET) Date: Wed, 30 Dec 2015 10:18:12 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20151230091811.GA19636@bunkus.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] On the multiplicity of Info elements X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 09:19:38 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, I only remember the discussion around Tracks being multiple, not particularly for the other ones. Our intent way back when was to allow muxers to write multiple instances of _the same information_ in different places in order to make the file more resilient against damage or incomplete downloads with protocols like BitTorrent. The same reasoning could be applied to Info. Both elements are absolutely crucial to playback; the other level 1 elements safe for the clusters simply aren't. > SeekHead, Info, Cluster, Tracks, and Tags are multiple. SeekHead and Cluster must be multiple. SeekHead in order to allow moving a SeekHead to the end of the file while still referencing it from the start (so that normal players will still find it quickly). Cluster for obvious reasons. > And Cues, Attachments, and Chapters are non-multiple. I have no idea why Tags is multiple and these three aren't. To me the following would make sense: - Info, Tracks =E2=80=93 multiple but only if each instance contains the sa= me information - SeekHead, Cluster =E2=80=93 multiple without restrictions - Attachments, Chapters, Cues, Tags =E2=80=93 single Kind regards, mosu --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWg6FTAAoJEHSvAK3y4yyF/moQAKc+8zP5U4FT7EX3iU0HlIq3 TgqaAoUQCJBx9OOBaEZc8hYiwpQ2HdSSM3mkkJtGI+NZ4R52ayI3xuJNz2W3a69f mnnkI2nsDy+Uuxjs8qRymYxARBLGMaJS0nR6vRu2+mtUHqVfMq1HkhUH8CuNVyYc X1Ipw4m0NRO6FbQ3yzsosbyTjbJvb9crglXt5Z7dRCoGujSbvI80hewUvTJd6pis 0hkIsz/SqrUqF4B1Zmr1rqWpXoZ3o1Blcx+9NRKfHeoOjP5y8sT28flyocWcECWA tab07rxEEEpYpRFxAs3o0mR3x3twQyquKD06LoQcJI0uR2qniIGc9EA6rATh23iC LuKG7cakvMLwrYBNFqNZSHeL1N22lSkY0Xx/aCjwOurNo5iEsZSRwugUu9gVcp5W quyWE7xwMTYwDv8QsR+bifOqgm/lwvFsakacd+PgD4Wu94n2NbpGlpsaEZG9tUsv aPhCVeVK9MbceSD+0A6ntLz18PVIiMLE9fnz+rguS8hqqTqiFDlSaOylxxRQWIyK KGCNt62ETiKbW9IPb2Fh3BhZUorq5vGItkJwmgrE7jww0C7XjGiKX3l+8DmYRFXR F7ia6wTUb1MZ8f/s6RILuoExSts6oDKps1XhnznSp3EQzEUaCexW8qJtyeZYSeHK lUjFAhXXbhvWqNePce7+ =izDX -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From nobody Wed Dec 30 05:43:59 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6EA1ACD03 for ; Wed, 30 Dec 2015 05:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 9HpBM4lPI0Ox for ; Wed, 30 Dec 2015 05:43:57 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876101ACD04 for ; Wed, 30 Dec 2015 05:43:57 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:42104 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aEH2h-001tH9-CP for cellar@ietf.org; Wed, 30 Dec 2015 08:43:56 -0500 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 30 Dec 2015 08:43:53 -0500 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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] [PATCH 1/2] Set VOID Element as multiple in EBML spec X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 13:43:58 -0000 Hi all, [trying out new method of sending patches to the list] I noticed that the VOID Element is set to non-multiple; however a = substantial amount of Matroska files seem to use void multiple times = within the same Parent Element. Such as: Segment/ Header/ SeekHead/ Void/ Info/ Tracks/ Void/ Cluster/ Cues/ This structure is current invalid according to both the EBML and = Matroska specifications, but I think that this is not an intended = restriction. This patch sets the VOID element to Multiple so the above = structure would be valid. Dave Rice =46rom f57062e0799cc39ec9a976a6c75d15ce0f0e2b6c Mon Sep 17 00:00:00 2001 From: dericed Date: Wed, 30 Dec 2015 08:36:38 -0500 Subject: [PATCH] Set VOID Element as multiple --- specification.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification.markdown b/specification.markdown index b90020c..28be745 100644 --- a/specification.markdown +++ b/specification.markdown @@ -344,7 +344,7 @@ Element Name: Void Global: Yes EBML ID: [EC] Mandatory: No - Multiple: No + Multiple: Yes Range: - Default: - Element Type: Binary --=20 2.6.4 From nobody Wed Dec 30 05:44:46 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3D71ACD0A for ; Wed, 30 Dec 2015 05:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 FhBON144_vGW for ; Wed, 30 Dec 2015 05:44:42 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD0121ACD05 for ; Wed, 30 Dec 2015 05:44:42 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:42104 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aEH3Q-001tH9-Ot for cellar@ietf.org; Wed, 30 Dec 2015 08:44:42 -0500 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 30 Dec 2015 08:44:40 -0500 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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] [PATCH 2/2] Set VOID Element as multiple in Matroska spec X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 13:44:43 -0000 Here is the corresponding patch for the Matroska spec to sync with the = prior patch to the EBML spec Dave Rice =46rom a86b557d0123c0f845365b986244332495aa2e03 Mon Sep 17 00:00:00 2001 From: dericed Date: Wed, 30 Dec 2015 08:42:34 -0500 Subject: [PATCH] Set VOID Element as multiple in Matroska spec --- spectool/specdata.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spectool/specdata.xml b/spectool/specdata.xml index 57abb97..42e331d 100644 --- a/spectool/specdata.xml +++ b/spectool/specdata.xml @@ -8,7 +8,7 @@ A string that = describes the type of document that follows this EBML header. 'matroska' = in our case or 'webm' for webm files. The version = of DocType interpreter used to create the file. The minimum = DocType version an interpreter has to support to read this = file. - Used to void damaged data, to avoid unexpected behaviors = when using damaged data. The content is discarded. Also used to reserve = space in a sub-element for later use. + Used to void damaged data, to avoid = unexpected behaviors when using damaged data. The content is discarded. = Also used to reserve space in a sub-element for later use. The CRC is computed on all the data of the = Master element it's in. The CRC element should be the first in it's = parent master for easier reading. All level 1 elements should include a = CRC-32. The CRC in use is the IEEE CRC32 Little Endian Contain signature of some = (coming) elements in the stream. Signature algorithm used (1=3DRSA, = 2=3Delliptic). --=20 2.6.4 From nobody Wed Dec 30 05:54:08 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785131ACD12 for ; Wed, 30 Dec 2015 05:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.113 X-Spam-Level: X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9G_dbqjyTED4 for ; Wed, 30 Dec 2015 05:54:06 -0800 (PST) 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 71DD01ACD11 for ; Wed, 30 Dec 2015 05:54:06 -0800 (PST) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 5AF7E505285 for ; Wed, 30 Dec 2015 14:54:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2015100101; t=1451483643; bh=oBcmXVuYdY4uOsfWzfqLfU0XLKKgLNS5SdS4LPU3CPA=; h=Date:From:To:Subject:References:In-Reply-To; b=BX9MhwJ0iBxpoWsMHILeFqlypX6gYuu3VwFefMwgcm2tfMtnvpYUyA/SpPxaAzQhs cO/AadXHKaEywMTR3Uohmsdo55U4t6jA4xHrm/qIdZcY3LHrZ6NIA5eMDnTs4ROFJJ RuAHs1tM0F9PrfRgNdTKwQDdAUSA41LK4YWEgMK3SSCo+qN36ugywdJR/iP5FHwDYC N9SmR9arsdQEAWGCzwdw4bJzhJefDLbTI9vb71No0Sw9n0Pn7L+Z+Xv2LVnekrfkw7 uIVJEkjCakkDdtWKk5rx/SCKXU1J59Jqwt4ldLJzNw7Ib66Ltn9HLwjmt+Sx3o3Pta KWXxkDWW5HgKm69ucgOC6SxaGWPldAxsoK7wpM8wBiEw6hxJAxUVRppBIdmE0Ebfhb nFcq3qblrf4W0tluMeDfJkllpTNZtTlq7t+5+uyJiqCBqKDKVCOxBQc1clYjjdPhpg YA3BOSEGAFdDmCZnyRnlpIS3ysC7qYtx8KmpZ3I6EWOn/OKNL2+JgC1fcsyHhFCGYS WUVramlLw6GUUnZpGYYfRDgQo/AoqlkfRvVWFJDAlKt47dIYBBjQc19/51No8M5JlH 9AqPAvxtog4oUF5pONFoupcS8NkI70a3v+YiryN8KWLdROUOWzYZYFJGmhKVvHr+gB 0HWuZaWC0syI85NoO+URmgMU= Received: by sweet-chili.local (Postfix, from userid 1000) id A6C46558376; Wed, 30 Dec 2015 14:54:02 +0100 (CET) Date: Wed, 30 Dec 2015 14:54:02 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20151230135402.GA3828@bunkus.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] [PATCH 1/2] Set VOID Element as multiple in EBML spec X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 13:54:07 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, +1. mkvmerge uses voids a lot, definitely multiple ones per parent. Apart from current, actual use the void's raison d'=C3=AAtre is to = be able to overwrite existing elements and placing their content somewhere else without invalidating the whole file (and without having to re-write it completely). Therefore voids should be made plural. I wasn't even aware they currently weren't=E2=80=A6 The patch itself LGTM. Kind regards, mosu --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWg+HyAAoJEHSvAK3y4yyFymIP/0I/bu31Ij2xFar1NIOO5FHA nHf2+Pbjuy9gDQhkJctpu5JbC0K9jHdyhiVEzE2ZGQUncc/n1stSNFgIbTK2ljmr yV8dwI4dBt57pcEDNRObOKEn2R4WlSZrjXVDxoKQgRoAUWR/5lTyzODhOQ7E0Ivv f/81n6HoiobWbxsQSV/rvLQlpfQxc9JULMVjJc0MLJ6usMkshoUyaUov1rEzciXB j+gBFB0BRn0v6UYuRVYHS7gSg9nZX8uizkUIrma72JCcq3eRy3TtUyACu4PUI7M9 PRnAfLIo7vW+IXT0pvFZnPJ/3f9+B4uH0bN4QxcXLlknd7syDQx+Dv0O5qjv6vSN 5MJm43H6pzXhjnJ3h4oc08bdagPtPFXlUWZ9Ip4DVtuOHkAC4WD78u8gxcqPs/CG 5msVBqJVsAP5bOhMiVQ8Urmo/m+EWCFjlslkfzUBd+73YlSBl9oOaD6hlLgQ+nku T6Rk+d4P866akA1CQSDPLgr9J5qFEZitnMTVfO81zeeZm/7qdp6Q6dvUAASzlOkn NXOaB+glJdqgr7TIwCgaNeYGM27XPZUuVEoAqTXmlhXBzx6QnUd61NnZjVfnDSR9 9wWX7A0sFXh2HK8uBmlWvoExEGvF6MQASTLE5kb0sTKurBXjs0BuuckRV7ZB8aqO srqA+cSYlY8nUPCK/A+u =t3m8 -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From nobody Wed Dec 30 05:55:01 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0149D1ACD13 for ; Wed, 30 Dec 2015 05:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 lQ0CiJBqZpyq for ; Wed, 30 Dec 2015 05:54:59 -0800 (PST) Received: from liselle.bunkus.org (liselle.bunkus.org [IPv6:2a01:4f8:151:7310::105:1]) (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 1D3B91ACD12 for ; Wed, 30 Dec 2015 05:54:59 -0800 (PST) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id F2052505E72 for ; Wed, 30 Dec 2015 14:54:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2015100101; t=1451483697; bh=x+3ApjseK4eAvJvNddtHFB5yXWOvxz0dmLCbyA8hByc=; h=Date:From:To:Subject:References:In-Reply-To; b=LNDwbxgptgRMAMRFn828g5TE2DqC0w51HhZXuOF2BPeYhHh8jbB+4wuQrOQsOvLRp 2LHQR1srwg1jyBqd/mMJyUv+R4Zw8CeGEanOfvM1W6LG0XRwHz95HaERiEzc7jCAkx ukZbNqnIdK0ia1FbzCE7wcP0mKj90ydyndSB0ArTW+lRF7WXML94hTD/sIorOY7It5 WCjnlU6WF4kqdT64GSVKQOB4oatsqtq8MXHcsjlAzgXdNAsjwoRVaRSNP3Id5eZn6t 28rbsSzo5xOf6J3BQWVCb3UyNATUC5PsWZr36i1aRGdOwMWI7E+KljW7haU3NAE+f+ yghtYrTedoPWS3f0XIyAAllBLbFsjSLA+R2FfcieKNM35lEA4G6wiv/Njmcff48StE GA/Ot690JqEvUBvHUsLRCVwH9jAZb2+V9Ccg973H4eHXITYVdvYzSTwbzh3bILtiN+ HDEFLPAmLBLLxWlvZL4uA3uA1nK+mMpkkVJi5Sez9E44EuhM6W1BozC87za0tWPsYz mOQKDGCq4sWpB1totCoeWtKU3VXoom7c16/wgffg7TG30jCSeSB7kDF6WY/ozMqB0g CkKsiPZfElU80bOQhoABW4Jsb9kZNEO2yEFo3OvvrEerkohjUG920M62QH+plf6WrV Pj0d5+4RYaBmTuQg597gwH0I= Received: by sweet-chili.local (Postfix, from userid 1000) id 77E6D55837E; Wed, 30 Dec 2015 14:54:56 +0100 (CET) Date: Wed, 30 Dec 2015 14:54:56 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20151230135453.GB3828@bunkus.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] [PATCH 2/2] Set VOID Element as multiple in Matroska spec X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 13:55:00 -0000 --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, +1 and LGTM to this, too. Same reasons as stated in the reply to the patch to the EBML spec. Kind regards, mosu --mxv5cy4qt+RJ9ypb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWg+ItAAoJEHSvAK3y4yyF2gYQAM2PhW12Fbu9MWQ9W0MtBzg+ Utv6O9NjRsB+GxpaaSDqSppODnT7ybweGLj9yH5VJu28GqqlqiICZor7vPWKu0xP a5miWDvhLnPerq+5K8utasX7mzhEFYqzure+hukt770kc9lOFgUDAzmMBA7l94dj JB9mqyczfZR9AlO21J2+B0l2fF2PGheUtDsLfcImedWvAJv+w0R9l9aiS6Ae1n/6 qulJvY+n9A8+04CFJeeAxdEDEw3vDL4CpkCEoP4CQgiJ5GOaaK1h+j/RDyF3+3tM cb+c6/7B4ozcJ9Qz+5NKmuHVBeAVjUeVaqPiHEAUqF62FnOZexPZzELI9IMoScuE A8WaJwSQnG3iYXWtFH+eEa++Uso2W3fo5O3a7d+pJKQmub/BVBlzLjlzI11ePJhX M2wjBq9Q+yO7WGo9l2fccwaWdlprqxwCaLMf8vhARKtDTn7UJW3ABgGoedzWLxfD Up73F+zA7Z8WJTLDSji+VkyR1HtdMW9Ov/N6R8lURXN+gZEFHu1du5eybzvPDsuM wWuL/xkT4iCWAZpC15kyc8fs4JZOD65jcE8UUT0ok5e/JtzNSPLdN1f0n6NL1Dwj xh/xpdqG1YJPXgXYKOpRiSxQ7ffQDMOvKD4tD6reoKuuVRGEV8oj9KhBkjpRVBFX m1Zt3Jn3/NfGSDTLEvm1 =IN2m -----END PGP SIGNATURE----- --mxv5cy4qt+RJ9ypb-- From nobody Wed Dec 30 05:56:33 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C311ACD15 for ; Wed, 30 Dec 2015 05:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 VIJTWq0ay6Hv for ; Wed, 30 Dec 2015 05:56:30 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0747F1ACD14 for ; Wed, 30 Dec 2015 05:56:30 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:44645 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aEHEq-0021PR-4h; Wed, 30 Dec 2015 08:56:29 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dave Rice In-Reply-To: <20151230135402.GA3828@bunkus.org> Date: Wed, 30 Dec 2015 08:56:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2E9579A9-D970-487D-9B37-5DAD9BDD373A@dericed.com> References: <20151230135402.GA3828@bunkus.org> To: Moritz Bunkus X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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] [PATCH 1/2] Set VOID Element as multiple in EBML spec X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 13:56:31 -0000 > On Dec 30, 2015, at 8:54 AM, Moritz Bunkus wrote: >=20 > Hey, >=20 > +1. mkvmerge uses voids a lot, definitely multiple ones per > parent. Apart from current, actual use the void's raison d'=C3=AAtre = is to be > able to overwrite existing elements and placing their content = somewhere > else without invalidating the whole file (and without having to = re-write > it completely). Therefore voids should be made plural. >=20 > I wasn't even aware they currently weren't=E2=80=A6 >=20 > The patch itself LGTM. I sent the patch via PR as well. I=E2=80=99m surprised that mkvalidator = wasn=E2=80=99t complaining non-stop about this restriction. Dave Rice= From nobody Wed Dec 30 16:09:54 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDFA1A00E2 for ; Wed, 30 Dec 2015 16:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 n84L8AI3MVZK for ; Wed, 30 Dec 2015 16:09:52 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBBE1A00E1 for ; Wed, 30 Dec 2015 16:09:50 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:36517 helo=[10.0.1.64]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aEQoN-003lhN-KN; Wed, 30 Dec 2015 19:09:49 -0500 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 30 Dec 2015 19:09:45 -0500 To: matroska-devel@lists.matroska.org, cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-1.0 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] test4.mkv and EBML Elements with Unknown Size X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2015 00:09:54 -0000 Hi Steve and Moritz, The Matroska Test file suite is at = http://matroska.org/downloads/test_w1.html. This includes test4.mkv = which is an example of a live stream recording. However the file = doesn=E2=80=99t appear to adhere to the EBML specs. It the file written = wrong or are we missing something in the EBML specification? Within this file is this extract from the beginning of the Segment = element to the end of the Element ID of the Info Element. 18 53 80 67 FF 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A = 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A = 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A = 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A = 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A = 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 15 49 A9 66 I understand that 0x18538067 is the Element ID of the Segment Element.=20= The 0xFF represents the case where as the EBML draft spec states, "An = Element Data Size with all VINT_DATA bits set to one is reserved as an = indicator that the size of the Element is unknown.=E2=80=9D Next, between the Element Data Size of the Segment Element and the = beginning of the Info Element there is 134 bytes of 0x0A! In this case = 0x0A can not be a valid start of an Element ID since for this file the = EBMLMaxIDLength is 4 (via the default). Thus the Segment Master-element = has child data that is not an EBML Element. Is the Segment Element here invalid since it contains immediate child = data that is not a part of a child Element or should the EBML draft = specification be updated to permit mystery data (sounds dangerous and = complex)? Is there any documentation existing on this scenario? Should a = parser keep reading from byte to byte until finding a valid Element ID = again? Dave Rice= From nobody Thu Dec 31 00:33:29 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DD41A0270 for ; Thu, 31 Dec 2015 00:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.688 X-Spam-Level: X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 KayViWQS73ni for ; Thu, 31 Dec 2015 00:33:26 -0800 (PST) Received: from liselle.bunkus.org (liselle.bunkus.org [IPv6:2a01:4f8:151:7310::105:1]) (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 541651A01E2 for ; Thu, 31 Dec 2015 00:33:26 -0800 (PST) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id E1ED2587010 for ; Thu, 31 Dec 2015 09:33:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2015100101; t=1451550803; bh=agrepN02a0xppzXBfIalC67HzeG52hJ3QOhe7QausIM=; h=Date:From:To:Subject:References:In-Reply-To; b=QaEMkqdsEyuE+HgIiVoUYTx72Ld5bIt2kradVk9kNI+w70kIHLJ31/B4DEacUEzFz ZfJBAfD6iHwg2q0LxRWnfdBhYPODZQQNNTp0FQqvtTpvCbnZdT9HougrQ3phN67yrr P94mPeQpazSFMYLWzX4q+ulVwN3FHBISK7FC66RNXFlbx0tybjbBZqtSbNu4p1YLdd Ud6CoT6oLfOWcLRCaUYQmgcQ40zAAXBB7GjAjBzILYQAckxYo4Ti1yV3a8lFmH+MhF CMknfGsqRNHJ7sudZQ1MXSktF/fw78hIgR84XzZYYwZYQh2Cn042cOOAhV1zEGeH/s TEm6UNWvbWR7FYzwokRO4xX7HZ32pZK2tG2r1FtIiEhyg6f4O1QtvDyEYot5/zKe2E 7gjA/kDOiwidxPeVwXFBdtB4mRvz2L9PAv5GjbaN1ino5M4sdamJuhqK5s8ry0V5Xe aMqQCwHvQUBi8TcIW8GZyPR8UcTYhXIKIG/tM4/T1Ylygo7enIoIjvTj0e8ShRIFy6 1vfyXl+Rzugb6tlVeN5IDEnCAmmSO9NAUVNi7mc02qulBc8obJJWwnjvrBl+aODQz1 76wlO5JeqcGrbkC7ezfNod4TTd5bQudYSgqAtvKH5ZV8sKbvbfoyq0Doae4SClAasH 1GnSCtn0k9buXyxxW4B/KMf8= Received: by sweet-chili.local (Postfix, from userid 1000) id 31ABB55E79D; Thu, 31 Dec 2015 09:33:24 +0100 (CET) Date: Thu, 31 Dec 2015 09:33:24 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20151231083323.GB15920@bunkus.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ftEhullJWpWg/VHq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] test4.mkv and EBML Elements with Unknown Size X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2015 08:33:28 -0000 --ftEhullJWpWg/VHq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, > The Matroska Test file suite is at > http://matroska.org/downloads/test_w1.html. This includes test4.mkv > which is an example of a live stream recording. However the file > doesn=E2=80=99t appear to adhere to the EBML specs. It the file written w= rong > or are we missing something in the EBML specification? > > Within this file is this extract from the beginning of the Segment > element to the end of the Element ID of the Info Element. > > 18 53 80 67 FF 0A 0A 0A=E2=80=A6 Uhm=E2=80=A6 this is indeed invalid. A master must only contain child eleme= nts, not additional data. To put it differently: all child elements of a master element must cover the whole space occupied by the master without any gaps in between. I honestly don't know that file was created. libmatroska contains programs to create a couple of those files in its "tests" sub-directory, but test4 is not among them. Judging from the download page you've linked it's possible that the file was created with mkclean =E2=80=93 in th= at case I would say that mkclean produces non-compliant files. Steve? > I understand that 0x18538067 is the Element ID of the Segment Element. > > The 0xFF represents the case where as the EBML draft spec states, "An > Element Data Size with all VINT_DATA bits set to one is reserved as an > indicator that the size of the Element is unknown.=E2=80=9D Correct. > Next, between the Element Data Size of the Segment Element and the > beginning of the Info Element there is 134 bytes of 0x0A! In this case > 0x0A can not be a valid start of an Element ID since for this file the > EBMLMaxIDLength is 4 (via the default). Thus the Segment > Master-element has child data that is not an EBML Element. Correct. Like I said, invalid. I definitely do not want to adjust the specs to allow arbitrary data in arbitrary places that a parser has to be able to skip over. Kind regards, mosu --ftEhullJWpWg/VHq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWhOhOAAoJEHSvAK3y4yyFmZ4QANFDY7O57OBcBgEj2HXg0dHs P9xacV80rHnNMlLDxXEI5UP27OBWi1bzeOrlhgrp52Oa8F+eoRRsocs+3op6aPPi zcQI69WgtYcyYAvxIoNtWuSCbyJg+mPfoHMiLMabyY3Kb9qxRbx+lISOLMRWMzj/ 7xEj0SCc+bq8/h3txSXnMsXV/HE8xgMP7qvJABb82TYROyKXNiulAk7R2dfnBCh5 OkTR5Odi+5ZlR1eY59CzgNSX1Kpz2Rz5qbaZm2jZIwmDnBG47PR5d0hcJE+/N1K4 JvGMgztaBBrSw6aY02IeaLeEketS6QxpWxryZCoap24fqQn6VB9L1leD+xSFe5t+ bJSKJoMHftXhmC85NXHhua+nHxNLcrpBM9Ci1Tg8wjn0BWShKmBrh5l4kl+nd2PI fFbGBTVR3ntIEKzRRv3xwn+/KC8Eg9t8hIH5w4nPZgRiIsmrRka8D9uPa1bV8kUk 25YUzuOqc+fs06NxZswHrj1BcEO4b6axRV4zspoDSSmoQpB/emsWiZ+DkwfBeArL 6Z+2ZdzJYQy6/Oh1E11+wtoRCLs9OWjO4X4/HvUORjQRJMhXvmtN2vRudQXbERve 45PUfSupGpp/Dp7/5OQehXQY0PouIUml4FDfhtouRTWlW0rC8iAKu/XYlslb460E yiD3SEjZweNDSaCFV60W =zX2U -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq-- From nobody Thu Dec 31 02:51:53 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB801A1BEF for ; Thu, 31 Dec 2015 02:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.399 X-Spam-Level: ** X-Spam-Status: No, score=2.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 GXACxC2rvBLD for ; Thu, 31 Dec 2015 02:51:50 -0800 (PST) Received: from 16.mo3.mail-out.ovh.net (16.mo3.mail-out.ovh.net [188.165.56.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479E81A1ADD for ; Thu, 31 Dec 2015 02:51:50 -0800 (PST) Received: from mail614.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo3.mail-out.ovh.net (Postfix) with SMTP id 62F3BFFAFE2 for ; Thu, 31 Dec 2015 11:51:46 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 31 Dec 2015 12:51:44 +0200 Received: from p508ba3f1.dip0.t-ipconnect.de (HELO ?192.168.2.101?) (jerome@francoallemand.eu@80.139.163.241) by ns0.ovh.net with SMTP; 31 Dec 2015 12:51:36 +0200 To: cellar@ietf.org References: <20151231083323.GB15920@bunkus.org> From: Jerome Martinez Message-ID: <568508B2.40704@mediaarea.net> Date: Thu, 31 Dec 2015 11:51:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20151231083323.GB15920@bunkus.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 628252148234588306 X-Ovh-Remote: 80.139.163.241 (p508ba3f1.dip0.t-ipconnect.de) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedriedvucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedriedvgddvtdcutefuodetggdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] test4.mkv and EBML Elements with Unknown Size X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2015 10:51:52 -0000 Le 31/12/2015 09:33, Moritz Bunkus a écrit : > A master must only contain child elements, not additional data. To put > it differently: all child elements of a master element must cover the > whole space occupied by the master without any gaps in between I have seen a bunch of files (I'll try to find them again, in order to see the writing library) with a NULL byte between some elements. Looking at the files I have right now, I found a file written by: Writing application : mkvmerge v2.6.0 ('Kelly watch the Stars') built on Mar 24 2009 15:23:17 Writing library : libebml v0.7.7 + libmatroska v0.8.1 (so an "reference" application?) with a NULL padding (1 byte 0x00 between "SeekHead" element and "Info" element). I guess this is due to the fact that a "void" element needs at least 2 bytes, so not possible to put one here. should it be considered as not conform? Maybe we should consider an exception to the rule "A master must only contain child elements, not additional data" with a single NULL byte as valid data and considered as a tiny "Void" element. Hex dump (from "SeekHead" to "Info", see the 00 before 15 49 A9 66) : 11 4D 9B 74 BD 4D BB 8C 53 AB 84 16 54 AE 6B 53 AC 82 10 A5 4D BB 8D 53 AB 84 11 4D 9B 74 53 AC 83 C5 50 27 4D BB 8D 53 AB 84 1C 53 BB 6B 53 AC 83 C5 4E D3 4D BB 8B 53 AB 84 15 49 A9 66 53 AC 81 43 00 15 49 A9 66 From nobody Thu Dec 31 02:58:29 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB451A21C0 for ; Thu, 31 Dec 2015 02:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.187 X-Spam-Level: ** X-Spam-Status: No, score=2.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_AVOID=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 voJ_n8OGp5AT for ; Thu, 31 Dec 2015 02:58:26 -0800 (PST) Received: from liselle.bunkus.org (liselle.bunkus.org [IPv6:2a01:4f8:151:7310::105:1]) (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 6406E1A1BE9 for ; Thu, 31 Dec 2015 02:58:26 -0800 (PST) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 67680588B6E for ; Thu, 31 Dec 2015 11:58:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2015100101; t=1451559503; bh=KsPhuNiH24LUZVIolVatxYK/ZWY1x/MpSzQXBI3eyyQ=; h=Date:From:To:Subject:References:In-Reply-To; b=tFfZGh1LEDMqEUOaPRevyhDv8TUvDTTb5IvkTFBE5hToBxb0TgZo9/50tU4xXOjVG FsUXHhHlCC2xEw1SCgGSlOfLuurniVb/9hnBU0hGghwSYopvboCh3a/66aaVLHaurG Sit9QXUjEGBys2nPDe32w/B7OQlf3RH3+tTSIms1tgwQEXpmKhbmiwjKFptqvzvDad FVFevujD6UAp2tXHoANbCntwM1TwJIh66ezk9YQbTunpBSUxRW8RhyRQ9/ARJWCWYP lI3TKbj1RnLh810SzSs3oEaU1StoDzqob0H1er6lGoCQDXEP52xNxPJ2F5WypBWyHm BSl0Z8NFGbA2z+zyChP4BOYgxuce6YtaRcL4ypaRFh1/KGePIxiLToKjXsRr4Vpdlz xQeRRrY64fkjW7ilG6W9zkMSDtzEp2tMjTFJ9mP9T6bpO7/RkmErmD5ELvGehlhmIh U9NL9+SbFmZI0XA/OCmCm5T5+nkqXMkFJ0moOSU8KmZg0DMPhtWfk1uq+cQxcFH8pN ChTTHIP4Zx3DtxEm4Tf0H0w+gQ+2wNg0dXPW1iR8LsBniEUYHgzqaWP8qjI67uhbWw oD51aT7IpHlCJvnBfYy8lVpdeXggvLELkMJQA3hlEDDHGR2MbVSt4XkRkKx5fMgtUy X+CD+pd50tOn5UHDhdgj6pps= Received: by sweet-chili.local (Postfix, from userid 1000) id E6D085635FE; Thu, 31 Dec 2015 11:58:24 +0100 (CET) Date: Thu, 31 Dec 2015 11:58:24 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20151231105824.GC15920@bunkus.org> References: <20151231083323.GB15920@bunkus.org> <568508B2.40704@mediaarea.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XMCwj5IQnwKtuyBG" Content-Disposition: inline In-Reply-To: <568508B2.40704@mediaarea.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] test4.mkv and EBML Elements with Unknown Size X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2015 10:58:27 -0000 --XMCwj5IQnwKtuyBG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, > Looking at the files I have right now, I found a file written by: > Writing application : mkvmerge v2.6.0 ('Kelly watch the > Stars') built on Mar 24 2009 15:23:17 It's quite possible that older versions of mkvmerge (and definitely of mkvpropedit the old GUI's header and chapter editors) did not handle this case properly. Those were bugs, and today's versions should be pretty great wrt. to this particular issue. > I guess this is due to the fact that a "void" element needs at least 2 > bytes, so not possible to put one here. Correct, but one can usually do and what mkvpropedit & the GUI's editors do is to move the following element's ID and size element one byte to the front. Additionally they extend the move element's size portion by one byte (e.g. writing 0x40 0x04 for the size instead of 0x84). > should it be considered as not conform? Yes. > Maybe we should consider an exception to the rule "A master must only > contain child elements, not additional data" with a single NULL byte > as valid data and considered as a tiny "Void" element. I don't like exceptions. Just because it's a bit harder to get it right doesn't mean it should be allowed. The more exceptions there are the more conforming parsers have to test. Yes, I know and like the principle of being liberal in what you read & understand but conservative & strict in what you write. But that also implies that we should encourage muxers to write good files; allowing sloppy things like one zero byte between elements does the opposite. Kind regards, mosu --XMCwj5IQnwKtuyBG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWhQpQAAoJEHSvAK3y4yyFKDwP/3cAW2V205tN0tjJJgxMlmLa 7rpV4uqDevzcWaDG4UZmwhOm5zx7NVv2XGUoT4rQMGy6MJ5rTXf8/auXYjfWeeFD G9KbbeeXvyciYEvs3wdBKUEJRQiEO5j9atvEWZNZxYqt0d28CpuxB6/SkdwpvdIH CbjHBijDdVw7lqhSli3QG71jxGMvm/ApUq7NdeqovYnLdvN1itfnwte7Y8/gaJDr zGUxVNdLSrpV5Ad2x4K0D11EYdhzPwd9de9YM9zjVgNfuTj99ZAvJhHVrdAllgHD wC/CNUpcHDhF8mjWf0mqe1mXTpT7PCTgfs1fT8IXKfoq8Mvf6qauXXO8B9ZX2eKP NEtvVtmHHcRlxOt7osMvkU6BbzxWzBR19vQMXkIqldl3jWihLLuKXcMrGEutJDSK W4YOc/p4AyfUzGK2rGRGx0jsZey1JIup9Babxuu/yIFbq60BtXIM0AoFpqtnKOIX bR/cJCQnaEI9ikjW2IJqG1jRo1Ad9RP+ZIUERmkHmePajfa2Hrg/ZqorfKZizuW4 rTHGb/Aw1FhPSd3vR6ygq+iluEzNAiAYkpNIVZJWBYwS4e3/S96Z0gF6YZbmt/O6 HptMK5sFZuhiaXSd4fRCK3OSjkvyEA0u0H7yieueAeqggztogQ2DJxb6KTJNAyij irTmzpLPrxY2s0lpwdZ6 =tQB4 -----END PGP SIGNATURE----- --XMCwj5IQnwKtuyBG-- From nobody Thu Dec 31 03:11:48 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB071A7001 for ; Thu, 31 Dec 2015 03:11:46 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 LbMQQv1Xbm0n for ; Thu, 31 Dec 2015 03:11:45 -0800 (PST) Received: from 13.mo3.mail-out.ovh.net (13.mo3.mail-out.ovh.net [188.165.33.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B6E1A7009 for ; Thu, 31 Dec 2015 03:11:45 -0800 (PST) Received: from mail614.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo3.mail-out.ovh.net (Postfix) with SMTP id 4773EFFAFEE for ; Thu, 31 Dec 2015 12:11:43 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 31 Dec 2015 13:11:41 +0200 Received: from p508ba3f1.dip0.t-ipconnect.de (HELO ?192.168.2.101?) (jerome@francoallemand.eu@80.139.163.241) by ns0.ovh.net with SMTP; 31 Dec 2015 13:11:30 +0200 To: cellar@ietf.org References: <20151231083323.GB15920@bunkus.org> <568508B2.40704@mediaarea.net> <20151231105824.GC15920@bunkus.org> From: Jerome Martinez Message-ID: <56850D59.20905@mediaarea.net> Date: Thu, 31 Dec 2015 12:11:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20151231105824.GC15920@bunkus.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 964333270781857938 X-Ovh-Remote: 80.139.163.241 (p508ba3f1.dip0.t-ipconnect.de) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedriedvucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedriedvgddviecutefuodetggdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] test4.mkv and EBML Elements with Unknown Size X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2015 11:11:47 -0000 Le 31/12/2015 11:58, Moritz Bunkus a écrit : > I don't like exceptions. Me neither. but in that case, the "reference" muxer had this bug, so there are some files in the wild with such thing. > Just because it's a bit harder to get it right doesn't mean it should > be allowed. The more exceptions there are the more conforming parsers > have to test. Yes, I know and like the principle of being liberal in > what you read & understand but conservative & strict in what you > write. But that also implies that we should encourage muxers to write > good files; allowing sloppy things like one zero byte between elements > does the opposite. We got the same kind of issue with FFV1, and I wrote that: bits_per_raw_sample: value bits for each luma and chroma sample 0 reserved* Other the actual bits for each luma and chroma sample * Encoders MUST NOT store bits_per_raw_sample = 0 Decoders SHOULD accept and interpret bits_per_raw_sample = 0 as 8. (this is due to previous reference encoder writing 0 instead of 8) Maybe we could use the same policy for the RFC of Matroska v1 to v3 (or v1 only? I don't know, the file I get is v1 but I don't know when this bug was removed from the library), and explicitly forbid it in future v4 only, and validators could provide a warning instead of an error for such files. From nobody Thu Dec 31 04:52:22 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51811A8824 for ; Thu, 31 Dec 2015 04:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 lkwZNhhKMoCs for ; Thu, 31 Dec 2015 04:52:20 -0800 (PST) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AFCB1A87E3 for ; Thu, 31 Dec 2015 04:52:20 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 820D6C23C4 for ; Thu, 31 Dec 2015 12:52:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chMIe-rmDk9Q for ; Thu, 31 Dec 2015 12:52:19 +0000 (UTC) Received: from [10.0.0.42] (c-24-63-237-33.hsd1.ct.comcast.net [24.63.237.33]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 2D018C14B1 for ; Thu, 31 Dec 2015 12:52:19 +0000 (UTC) Message-ID: <56852502.7060708@xiph.org> Date: Thu, 31 Dec 2015 04:52:18 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: <20151231083323.GB15920@bunkus.org> <568508B2.40704@mediaarea.net> <20151231105824.GC15920@bunkus.org> In-Reply-To: <20151231105824.GC15920@bunkus.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] test4.mkv and EBML Elements with Unknown Size X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2015 12:52:21 -0000 Moritz Bunkus wrote: > test. Yes, I know and like the principle of being liberal in what you > read & understand but conservative & strict in what you write. But that > also implies that we should encourage muxers to write good files; I encourage people to read , although as an expired individual draft I do not claim this represents the official position of anyone at the IETF beyond its author. From nobody Thu Dec 31 05:03:55 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20E21A8844 for ; Thu, 31 Dec 2015 05:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 P2Og5EOaovne for ; Thu, 31 Dec 2015 05:03:54 -0800 (PST) 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 A4F5B1A87EC for ; Thu, 31 Dec 2015 05:03:53 -0800 (PST) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 3C4F159248C for ; Thu, 31 Dec 2015 14:03:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2015100101; t=1451567031; bh=1dA/+mfJu7rZTQ9b+8f3TKCbt71QcW5Mdi1DMKHey1I=; h=Date:From:To:Subject:References:In-Reply-To; b=5jMWdHBiRXDizzlmhf+y+Q6znYjpLtsLY3D66Bq3g+Ei6TKIgKEaxI9NMoq+qP/6+ sfKJ3TscXc2GzgEoYrlRG3RvHUuQ0Lfb6944UjIAzg4gZT6sFEgjjlM4oyw0JCW7F9 9bUOq55Pzwy+DP4qVrxogq4Gx4fFhnaCTmlCsQ65bMV6GP5KYGVCZjZz6V2KBAz6XZ woOkUVkwB2yPMn6m3twWvcOg/K7kcnVaOJnjqdUJQ8LG57LvPDwz7h3lTX/YUyDSVO qLN74tNfEpVDm68jov0KhdJrA5DKOOR9CJUoByLmd8r5XbSd02oLgjQ4J1F0PY9hff Ge0rkimGQAFBH5YuCi64b9hlnH/hx4sCcRWZI02bcDlO5BMTXMB5G+okRPu/cMu3b1 PGE5LzH69b2iz1e6KddBXoVOEtTnHe5D0FGelFWlEl7VQJ4T3oGKinnvf7MKD8YcGu ShYf3APXzGlKD0LWa7vF75sCyxdXDidq4dN22PAjVBtkSsZgxaZitv3dyLKhm78iIc cBPCGZpFEVoPNSYKVF3eqTOmEGvdjDa0yPxD3+Ra+aWNchtAtGD29VSxmGMFmFlGk9 CrTv/H1qnZBpgbJNPrgnpAagC9pcukwHuaqkRVtyjb0jKExyLqxwpJ7RHMSgHGoA1i 1CfHRO9iVkg8/Zg83bFVV9Lo= Received: by sweet-chili.local (Postfix, from userid 1000) id 1282F56E368; Thu, 31 Dec 2015 14:03:53 +0100 (CET) Date: Thu, 31 Dec 2015 14:03:53 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20151231130352.GD15920@bunkus.org> References: <20151231083323.GB15920@bunkus.org> <568508B2.40704@mediaarea.net> <20151231105824.GC15920@bunkus.org> <56852502.7060708@xiph.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3Pql8miugIZX0722" Content-Disposition: inline In-Reply-To: <56852502.7060708@xiph.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] test4.mkv and EBML Elements with Unknown Size X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2015 13:03:55 -0000 --3Pql8miugIZX0722 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, thanks for pointing this out. "Be as strict as you can be" is roughly what I had in mind. Jerome pointed out that earlier files which contained e.g. that one-byte gap were created by the reference muxer, mkvmerge, and that it would be detrimental to consider such files invalid. That's why he proposed such an exception. However, the same reasoning could be applied to all the bugs mkvmerge had in the past. Where would that end? What about bugs where mkvmerge clearly violated the specs and where interpreting the data according to the bug is incompatible with interpreting it according to the specs? This cannot be solved properly, hence my vote for "no exception". It's also clear that you cannot judge files by our upcoming Matroska RFC specs that had been created before that RFC has been ratified. This should probably be signalled somehow, for example by using the Matroska version number. As v4 is already used in reality (even though we haven't finalized it yet) bumping this to v5 for the RFC would be an option. Kind regards, mosu --3Pql8miugIZX0722 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWhSe4AAoJEHSvAK3y4yyFOsYP/jk3ZxDJNK4uGA9GLakyLnHV 87/B4kjbjlI9oSaCmPZrfLaw9gEFZFz0kWrowGMPZvVCmdqiawUpCQBlIWCP/4up 6kE+6ZNxDNJCAZSqaRexjT6oItFppr5zCIIwYj0LDQCGTLjjUHShVNLvHC3QxVxz HCmL3oDutqIxlyuliQ62psi5OLRssuaTaZ0HjCFFFrZsKe3CzOeCETjbhW7xp9zA YJtngy8NJAeL3UzkMaWLiW4GTRwjjnrRgeV5fkI6WW/KsA1NRbKDOub+E7J3fPVi 2R9yZyOCRbSnlJvZhf2taXltglR3AOd68ukrXadotWAqug2JiAuppkZ5Mtv17q7L BU4bl9BL0dTZqCRRrlQh7pb7saD9InKf/jC+rPId4JNZatx4w+ykHFUsoRpTYXpo G7ZIhmE7R5egweM1LkvM/e1NduRaLu29QtSQMsvfmn4Qp7cmqH8AOha/OKH2Kx9Z QD0/2E9prGMlO/QEr//+l7XWj0GzDdLGm2MPOfoepjoqxfPxxQxx8B80jGZfcEQD qb2Bt8PALT6U5YglSaeXVyQ0icuHbL3WwJDYanmNjITkjhjZYtZuuNsgYHB7NFo3 cVMCdaVwIV06Zgc7aLcIdFR/LQxE4oEshCIMq5AwkaO4xDNf610Zs328VpEF8NOn wpKt/h0HOgDeDdn2o/Gp =5G8O -----END PGP SIGNATURE----- --3Pql8miugIZX0722-- From nobody Thu Dec 31 07:20:40 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB681A1B0D for ; Thu, 31 Dec 2015 07:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 p-hygI_MrLOE for ; Thu, 31 Dec 2015 07:20:37 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 076FA1A1B0B for ; Thu, 31 Dec 2015 07:20:36 -0800 (PST) Received: from [192.168.2.129] ([188.100.175.162]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lu8Ri-1a5PJk1f9S-011VHc for ; Thu, 31 Dec 2015 16:20:34 +0100 To: cellar@ietf.org References: <20151231083323.GB15920@bunkus.org> <568508B2.40704@mediaarea.net> <20151231105824.GC15920@bunkus.org> From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE X-Enigmail-Draft-Status: N1110 Message-ID: <568547C3.1060607@gmx.de> Date: Thu, 31 Dec 2015 16:20:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20151231105824.GC15920@bunkus.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:SWAqS5ltfL8xznE4LElSvamRmC6mEjykvCCQK1x6sgUvX6A2M6U J+Xbi4c94SI+TBnN2Hlw6QlSj9LKpak0x7NxjtS87V/zBPogqB5BKfdWZWUNFoWHW6a4pfg t79jLmJmwbzIPZihxqgUNrzrXFXc7QPZFtYsDnDulr+rr3JHj4GbuTN2swD1EDMdR4+MB3u 3t6lw6rxZojZUXd1MKyuA== X-UI-Out-Filterresults: notjunk:1;V01:K0:u1X0lO7hKsc=:ada7lp1D3z69INqE6yYLHU 1eoGiZdlYPxzd3ZkskSGnKnFe0qne0mg0xS+/GUVx6PUhg+zDc13JlR7q8evc33kYr8WD/mMg MADtbY/ANKkmbZtl/r6o+FWu603UXQY3oDahNdYRYyw6C+ioSSdI3npzVBFGNi0nEUYO3FGW0 JDyaENtdoYgGYOiycF5OZkXUTjvzn8geizDy+RkKsSXQRBCL2Dva8FMWxfY5WzzkCOeRbGmyR avQLRwF50SWsAnLr/ox1vcIy6uVy3Fj3MJ4n+hphBl+J8pGbvkXJcHGWA0QvNyusqW5OzxV5+ SQQW6JacfAk03ES/9r8uWxf9ghhC/ACZq21ZuVrNRfaB7audZ18+osIbrA+HBQA05oGkeqEef PNspJmjmoPlUSlp+NwqIasYyaTJbkpeILD5tAvIlw1XZetOjOtDDj+y81gSbBE2oCfAtbInoM qkxULuJuosUZINNXZfTwZhSEORM4r9l6l8bCwCngYLFbNxeamfgXbb+r42zn2W73W5zBv1uPF KrrjcJOYmpLKI4d0tYWzWPrHxtthzkyTkj90Nyg0Rx4fm8bsFTJwLb3feokV6Ny4j3nE8ZL0Q 6FOYY6J6bHOSoJGhX4f3sldnJsRXejc+t35RpVp/kPKpT2gTswKC1X7Ioiwo9kGaPkCF4oYtM hWn4ZylQTkrprUJ1JwIh/lTNvpKDcJWsdr1jTu42RChoX6kpi+YyoxLwt9mTi36EzXdccv2h7 Rvy95Mk9A7hCywKpwe9FjIjT4Sd98E5dXXstgWGK9zm/aV3OuG3daHKxaPiYX0PgGV/RA0Dcg PZqFAAM Archived-At: Subject: Re: [Cellar] test4.mkv and EBML Elements with Unknown Size X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2015 15:20:39 -0000 31.12.2015, 11:58 Moritz Bunkus: Retrospectively I now know where the trouble with test4.mkv may have originated from. Back in 2011 I throw the test suit against some players on the Windows platform. None of the players could play the file. Most just did nothing, VLC even crashed. Two started playing, but just for 2-5 seconds. Not even with Haalis' Media Splitter the players would play the file. I suggested to take a closer look at the test suit to at least one players development team. I am unaware if anything got changed on how the player would handle test4.mkv. > Correct, but one can usually do and what mkvpropedit & the GUI's editors > do is to move the following element's ID and size element one byte to > the front. Additionally they extend the move element's size portion by > one byte (e.g. writing 0x40 0x04 for the size instead of 0x84). > >> should it be considered as not conform? > > Yes. mkvalidator is expected to complain, I assume. This would be true for all tools that check if a file conforms to the specification. Is mkclean expected to correct this? >> Maybe we should consider an exception to the rule "A master must only >> contain child elements, not additional data" with a single NULL byte >> as valid data and considered as a tiny "Void" element. > > I don't like exceptions. Just because it's a bit harder to get it right > doesn't mean it should be allowed. > > The more exceptions there are the more conforming parsers have to > test. Yes, I know and like the principle of being liberal in what you > read & understand but conservative & strict in what you write. But that > also implies that we should encourage muxers to write good files; > allowing sloppy things like one zero byte between elements does the > opposite. > It does not seem to be correct and there does not seem to be a benefit to it, so I agree to not having an exception. I am under the impression that demuxers will not stop handling files with that error. Well at least not for 'old' files, because it would harm backward compatibility. Having them not handle (or have them raise a flag) v5 matroska files with that error would be fine on the other hand. Best Regards, Sebastian From nobody Thu Dec 31 12:27:10 2015 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB2A1A8AD2 for ; Thu, 31 Dec 2015 12:27:08 -0800 (PST) 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=[BAYES_50=0.8, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 DlJZQp6fRtcp for ; Thu, 31 Dec 2015 12:27:06 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3A91A8AD1 for ; Thu, 31 Dec 2015 12:27:06 -0800 (PST) Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 30C2E1720AC; Thu, 31 Dec 2015 21:27:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id EfJtJ0lFbDOt; Thu, 31 Dec 2015 21:27:03 +0100 (CET) X-Originating-IP: 213.47.64.66 Received: from localhost (chello213047064066.6.14.vie.surfer.at [213.47.64.66]) (Authenticated sender: michael@niedermayer.cc) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 8EB9717209F; Thu, 31 Dec 2015 21:27:03 +0100 (CET) Date: Thu, 31 Dec 2015 21:26:18 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20151231202618.GZ22600@nb4> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rR6pEsNFzVJhSSrj" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] [FFmpeg-devel] clarification on General Description for FFV1 Draft Specification X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2015 20:27:09 -0000 --rR6pEsNFzVJhSSrj Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 31, 2015 at 11:41:22AM -0500, Dave Rice wrote: > Hi all, >=20 > I=E2=80=99m reviewing the FFV1 Draft Specification [1] and commenting her= e specifically upon the General Description section and have some questions= to clarify the meaning of this section. I=E2=80=99m cross-posting to ffmpe= g-devel though responses are welcomed on either list though encouraged on t= he IETF Cellar working group listserv [2]. >=20 > The General Description section [3] contains this introductory paragraph: >=20 > "Each frame is split in 1 to 4 planes (Y, Cb, Cr, Alpha). In the case of = the normal YCbCr colorspace the Y plane is coded first followed by the Cb a= nd Cr planes, if an Alpha/transparency plane exists, it is coded last. In t= he case of the JPEG2000-RCT colorspace the lines are interleaved to improve= caching efficiency since it is most likely that the RCT will immediately b= e converted to RGB during decoding; the interleaved coding order is also Y,= Cb, Cr, Alpha." >=20 > Two colorspaces are referenced, YCbCr(with optional Alpha) and JPEG2000-R= CT (Reversible Color Transform), but the RCT sentence doesn=E2=80=99t refer= ence planar storage. Does an RCT encoding store with planes and if so how m= any places are used and what are their names (3 planes or one packed plane)? the RCT case uses planes interleaved at line granularity > Also is storage of an alpha plane with RCT planes allowed? I think theres nothing disallowing that combination, so it is allowed >=20 > What is the meaning of =E2=80=9Cline" in the paragraph above? What does "= In the case of the JPEG2000-RCT colorspace the lines are interleaved=E2=80= =9D mean? a plane is a 2 dimensional array of integer samples a line in this context is meant as a horizontal line in that array that is a set where the second coordinate is always the same I think at least the word "horizontal" should be added somewhere line interleaved is meant so that a 4x3 slice with 3 planes YYYY UUUU VVVV YYYY UUUU VVVV YYYY UUUU VVVV would be stored as YYYYUUUUVVVVYYYYUUUUVVVVYYYYUUUUVVVV (left to right, top to bottom) or as in for (all horizontal lines) for (all planes) for (all samples in a line of a plane) store sample >=20 > Re: "Each frame is split in 1 to 4 planes". I'd like to be more specific.= From this reading it seems like 2 planes is possible; however, are 2 plane= encodings possible (grayscale with alpha or Y with only Cb)? Y with alpha is possible Cb without Cr is not possible >=20 > Re: "since it is most likely that the RCT will immediately be converted t= o RGB during decoding=E2=80=9D. Is there anyone other conversion possible? In theory the raw RCT values could be returned, thats purely a API/implementation question and would have no effect on the ffv1 format thats similar to using YCbCr values from NTSC/PAL instead of RGB NTSC/PAL isnt affected by what a device turns it into [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA --rR6pEsNFzVJhSSrj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlaFj2oACgkQYR7HhwQLD6vttQCfUB/xcYwP8GyavSgGUXTTI+aL Q1IAn38T2IIlwM3/NT6ySAx1v5bcXHOz =14F8 -----END PGP SIGNATURE----- --rR6pEsNFzVJhSSrj--