From nobody Mon Apr 9 09:02:44 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4099D12D574 for ; Mon, 9 Apr 2018 09:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoCvNbSv2IfO for ; Mon, 9 Apr 2018 09:02:41 -0700 (PDT) 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 C5F2F12025C for ; Mon, 9 Apr 2018 09:02:41 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w39G2ebE005053 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 9 Apr 2018 11:02:41 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_54BC09AB-1F25-4089-8FF0-FFF7F0CA9C82"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: Date: Mon, 9 Apr 2018 11:02:34 -0500 Cc: "Timothy B. Terriberry" To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [Cellar] CELLAR Chairs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 16:02:43 -0000 --Apple-Mail=_54BC09AB-1F25-4089-8FF0-FFF7F0CA9C82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi CELLAR Participants, As some may have heard, Tessa stepped down as co-chair prior to IETF = 101. We are currently looking for a replacement co-chair. Suggestions = are welcome; given the current state of the CELLAR milestones, I=E2=80=99d= like to find someone experienced with moving work through the IETF = processes. Tim will remain as the other co-chair. I=E2=80=99ve asked him to = expedite the working group last calls for the appropriate documents. Thanks! Ben. --Apple-Mail=_54BC09AB-1F25-4089-8FF0-FFF7F0CA9C82 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrLjpoACgkQgFZKbJXz 1A14iA/9E14BXqrBw2raN+Gdd3geJuBjyZOaAeoER1XUdLydUO5cNa1JayO9moAA KZ3zQuqAi98i25eyIvDe6kYhBPHyJNfQs78ejnZtZYAsCLdvg69P4IprqRbjIkjq Z6sLkYpdYB9U28KshdwMdOe3w+8qd+VInwaNq3kCu9p/r3892E27fQNaFSCkABRT 5J95cI+XvOFDszlpb5zw4J5OhobTjYLg35/OxYYV9iecjQLRGUF1k0MszwvCd13I Kmj4QGfhkGVtGmV2msf6O7snXHJbRESekx6hq/zmyMsrjGu97T+mHdtSBsiNcXxi nUkiXnEbxZni8yJ4k0w+KP6OQIvhtCvqJcKYuzYUP3lfrdQ03DvZKXAuea0akkDF s4XpNd6aCDTsnFyhjCOP8qnZsMGHKhFTcxrORG3VVEoEL5yQVf6Ja4lYVsF8mkcP 8TI2k4H+JT/qGjhTFLxt9KyAb/2OQ4W8cf2X3RWBOiaZcfA36dge+MGQbnN2A3u0 LNVJWk34++GUPRMTBnoLmH07RKdGdAHLv9NpeJV3PIhgkoyPYCOwh8cd1l6IkHfR bSlnOK3zwx4gtuhE8TYcnsFli2by4Kb0VWMP6Lr6kkP3A+bXjmaT1H/4zWBhqRdX K02bsl6C1Iy1H2WEIFIdjK1NpCYreSPwo2FhRMRYo68NP/43nvw= =5oAp -----END PGP SIGNATURE----- --Apple-Mail=_54BC09AB-1F25-4089-8FF0-FFF7F0CA9C82-- From nobody Fri Apr 13 02:35:55 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAC01242EA for ; Fri, 13 Apr 2018 02:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v504IVLbeVRr for ; Fri, 13 Apr 2018 02:35:51 -0700 (PDT) Received: from 16.mo6.mail-out.ovh.net (16.mo6.mail-out.ovh.net [87.98.139.208]) (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 DACB8120721 for ; Fri, 13 Apr 2018 02:35:50 -0700 (PDT) Received: from player755.ha.ovh.net (unknown [10.109.105.78]) by mo6.mail-out.ovh.net (Postfix) with ESMTP id B64781526BB for ; Fri, 13 Apr 2018 11:35:45 +0200 (CEST) Received: from [192.168.2.120] (p3EE2D9AA.dip0.t-ipconnect.de [62.226.217.170]) (Authenticated sender: jerome@mediaarea.net) by player755.ha.ovh.net (Postfix) with ESMTPSA id B92292600B9 for ; Fri, 13 Apr 2018 11:35:43 +0200 (CEST) From: Jerome Martinez To: Codec Encoding for LossLess Archiving and Realtime transmission Message-ID: Date: Fri, 13 Apr 2018 11:35:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Ovh-Tracer-Id: 8786522876651245713 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedriedvgddukecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: [Cellar] Adding private elements to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 09:35:54 -0000 I am working on a project related to Matroska and I would like to add some private elements to Matroska, at different levels (TrackEntry, BlockGroup, Segment). These elements add no specific features for media playback. As there is no indication about how to add private elements (no element is reserved for hosting private sub elements), Matroska conformance checkers currently flag new elements as "unknown". I would like to debate about how to add new elements to Matroska, for some specific needs so more flagged "private", and for future needs for Matroska (e.g. HDR metadata was added during CELLAR work, what should be done in the case CELLAR already released the spec?). Some questions: - IMO a new element should not make a new version mandatory, as new element are ignored by players, but what should be the behavior of a conformance checker? error raising if the element is not known, information only? Maybe we need a paragraph about it in specs. - How to manage private elements? Difficulty is to be sure an element identifier used by third party A is not reused by third party B due to B not knowing about A.On my side I suggest to just add it to ebml_matroska.xml without specific details in spec itself, see https://github.com/Matroska-Org/matroska-specification/pull/223/files for an example, so everyone is aware of identifiers reserved for a third party tool. Should such elements be in a separate document, mp4ra style? Jérôme From nobody Fri Apr 13 04:56:04 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBC61270FC for ; Fri, 13 Apr 2018 04:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fWN45mY3gDR for ; Fri, 13 Apr 2018 04:56:00 -0700 (PDT) Received: from mx01.mail.netstorage.at (mx01.mail.netstorage.at [IPv6:2a02:2410:b000:101:3000::c]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B6E1242F7 for ; Fri, 13 Apr 2018 04:55:59 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx01.mail.netstorage.at (Postfix) with ESMTPS id BC434A0059 for ; Fri, 13 Apr 2018 13:55:55 +0200 (CEST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 5713081E87 for ; Fri, 13 Apr 2018 13:55:55 +0200 (CEST) Received: from [127.0.0.1] (HSI-KBW-46-237-252-214.hsi.kabel-badenwuerttemberg.de [46.237.252.214]) by mailix with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128) ; Fri, 13 Apr 2018 13:55:55 +0200 To: cellar@ietf.org References: From: Tobias Rapp Organization: NOA GmbH Message-ID: Date: Fri, 13 Apr 2018 13:55:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20180413115555.10259.61468@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com Archived-At: Subject: Re: [Cellar] Adding private elements to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 11:56:03 -0000 On 13.04.2018 11:35, Jerome Martinez wrote: > I am working on a project related to Matroska and I would like to add > some private elements to Matroska, at different levels (TrackEntry, > BlockGroup, Segment). > These elements add no specific features for media playback. > > As there is no indication about how to add private elements (no element > is reserved for hosting private sub elements), Matroska conformance > checkers currently flag new elements as "unknown". > > I would like to debate about how to add new elements to Matroska, for > some specific needs so more flagged "private", and for future needs for > Matroska (e.g. HDR metadata was added during CELLAR work, what should be > done in the case CELLAR already released the spec?). > > Some questions: > - IMO a new element should not make a new version mandatory, as new > element are ignored by players, but what should be the behavior of a > conformance checker? error raising if the element is not known, > information only? Maybe we need a paragraph about it in specs. > - How to manage private elements? Difficulty is to be sure an element > identifier used by third party A is not reused by third party B due to B > not knowing about A.On my side I suggest to just add it to > ebml_matroska.xml without specific details in spec itself, see > https://github.com/Matroska-Org/matroska-specification/pull/223/files > for an example, so everyone is aware of identifiers reserved for a third > party tool. Should such elements be in a separate document, mp4ra style? There has been some discussion about private elements on the list: https://mailarchive.ietf.org/arch/msg/cellar/GwatcU8PFLwC4FFFWVyriDZtPR8 I think the best option would be to reserve some identifier range for private use (similar to Private Use Area in Unicode). Regarding new to-be standardized elements: The question seems to be when to increment the DocTypeVersion value in a muxer application. Only when the standard is complete or already when it's clear that the element will be added? Regards, Tobias From nobody Fri Apr 13 12:13:33 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CA712785F for ; Fri, 13 Apr 2018 12:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WG97-eSZNDuZ for ; Fri, 13 Apr 2018 12:13:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 1603112783A for ; Fri, 13 Apr 2018 12:13:28 -0700 (PDT) Received: from [192.168.2.101] ([93.242.75.28]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lw2dd-1eNxnv2vTZ-017jmq for ; Fri, 13 Apr 2018 21:13:26 +0200 To: cellar@ietf.org References: From: hubblec4 Message-ID: <3318390e-0647-289d-d52b-e2c9678b24f7@gmx.ch> Date: Fri, 13 Apr 2018 21:13:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5B9174D4CDB77CD70EF4349B" X-Provags-ID: V03:K1:t50kdI+89XcaUWEyfj1gACNcOHu/MH3pdzB0QdRPlidNfkefTzj JsqYR7CUPsmJTUTW+n56AvOPdk8qrVBGSDdj7jIYL2rLm2OTmQ914bjnCG2qzFQpBWXjNxE aeaQl1qQRhkR6eWxgFP81jfPmH5w+ya958q8gY2RZUneu8+7c/Ut+xRqaXFp91hiXR11lG0 PMKHZ7+ievp1hNCn7etBQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:GZfo9mMclSo=:d46H9Jtp6qT3YMgXFOv3xw Xs1qjTwEFZVOE9dQYTtlFUV6BftFTqUncggpJB03VemvWWfANeta1BWBcehchqUU+0v9um1JC iecOAdCNogi7y83Ob0hdSM26ZocxX6b7/NEI8xjwMjLruRenJGnWEkfRyabpXo9rP6Wvu60f5 UvhJyZvpGrvayRE6M4pb1AflqYGKGlZ6f/3rkXKyesJR1oFhiEOBd/kvngDyn+Vjn2e8gB66k xdWg6nDx5L8oq/PpUOxHYHOBT5vihIDXmiuK/2faPCQusiNC9zY6+l323RfbrnNrvbqIW5XIJ fObm6MQgGe9QxCoiJh5G6tvCfCHX8CgNpo4A4rLpS9F5ZjGzbErlsCLG37Z9sSSMHNfxO6Nzk boUd7bytk/6j/NdnU2f5ZrgKt6hk3FRgXkO/yH6nX16+10GowUJ4f3TjxQgyRtZK3p/Mf4/mD zhxpKyIeEkxJyV4U+im5V2c8Tnbwb54UXxgCDWhw6c1ZkHT6zP3QGIfY6cKrD3KP1BAUsLL7M khqc1kiztW3WVt+fNbWPTDZhQ9ko4lsjTcbTnJd5tK/CwiWJZMdm+Z71cDU3qZtieC73UuGlg 6m7pu3nUJKAZwsb/z5qZzjBF8/OTFKT2TZDcO1Q0rQxOU7gd0tXAEpcktjaboZys+H1Faeb3n zzgRb0LLEUvFkYeK+3Y9DOaZYhz1O2/5h8FK+Bl7DGKWObtjGvRwUP5hAvMj6w0qP6GDLNAKu 7FnE9LMr4KOQrFb2mRgsb48OJcGST7PcKk5vIbK6NLTGstIUeAxaVGsYdRe81NRYvUjIfOdTr PxarlBKjNHGl9bCA8cj5pglReBjJTU0UI1dzkxJoAzvAwON014= Archived-At: Subject: Re: [Cellar] Adding private elements to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 19:13:32 -0000 This is a multi-part message in MIME format. --------------5B9174D4CDB77CD70EF4349B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, Am 13.04.2018 um 11:35 schrieb Jerome Martinez: > I am working on a project related to Matroska and I would like to add > some private elements to Matroska, at different levels (TrackEntry, > BlockGroup, Segment). > These elements add no specific features for media playback. > > As there is no indication about how to add private elements (no > element is reserved for hosting private sub elements), Matroska > conformance checkers currently flag new elements as "unknown". > > I would like to debate about how to add new elements to Matroska, for > some specific needs so more flagged "private", and for future needs > for Matroska (e.g. HDR metadata was added during CELLAR work, what > should be done in the case CELLAR already released the spec?). > > Some questions: > - IMO a new element should not make a new version mandatory, as new > element are ignored by players, but what should be the behavior of a > conformance checker? error raising if the element is not known, > information only? Maybe we need a paragraph about it in specs. > - How to manage private elements? Difficulty is to be sure an element > identifier used by third party A is not reused by third party B due to > B not knowing about A.On my side I suggest to just add it to > ebml_matroska.xml without specific details in spec itself, see > https://github.com/Matroska-Org/matroska-specification/pull/223/files > for an example, so everyone is aware of identifiers reserved for a > third party tool. Should such elements be in a separate document, > mp4ra style? > > Jérôme I have read your PR in Matroska (yet nobody has answered) and it is first time reading about RAWcooked. I'm sure there are not much people how know about this project. To add new Matroska elements for this "little" project is in my eyes too much. But I can understand how important it is for you and the project. I wait already a  long time for a PR but It has become quiet around Matroska. When I have more time to work on Matroska Menu I'm afraid it will take a lot of time to add new elements. Then I thought about this problem and maybe is the solution useful. Inspired by Haali TRACKSETEX which uses the Matroska Tags! Here my suggestion: Add a top-level Tag with a SimpleTag with Title RAWCOOKED. Then add for all your RAWcooked elements nested-SimpleTags. In the RAWcooked project is a RawcookedBlockGroupelement(probably very often used) which is distributed of the entire file. To collect all RawcookedBlockGroup values, you must read the entire file which takes a while, but with Matroska Tags a reader needs less milli seceonds. You could change all RAWcooked element values without re-muxing the mkv file. You could change the RAWcooked project structure and have also backward compatibility. Every "private" project could add his own Matroska Tags structure. Every developer can then decide which projects are supported(Matroska reader/Splitter). For HEVC Hdr data we should add new Matroska elements because this are stream base data. Kind regards Martin Below --------------5B9174D4CDB77CD70EF4349B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi all,


Am 13.04.2018 um 11:35 schrieb Jerome Martinez:
I am working on a project related to Matroska and I would like to add some private elements to Matroska, at different levels (TrackEntry, BlockGroup, Segment).
These elements add no specific features for media playback.

As there is no indication about how to add private elements (no element is reserved for hosting private sub elements), Matroska conformance checkers currently flag new elements as "unknown".

I would like to debate about how to add new elements to Matroska, for some specific needs so more flagged "private", and for future needs for Matroska (e.g. HDR metadata was added during CELLAR work, what should be done in the case CELLAR already released the spec?).

Some questions:
- IMO a new element should not make a new version mandatory, as new element are ignored by players, but what should be the behavior of a conformance checker? error raising if the element is not known, information only? Maybe we need a paragraph about it in specs.
- How to manage private elements? Difficulty is to be sure an element identifier used by third party A is not reused by third party B due to B not knowing about A.On my side I suggest to just add it to ebml_matroska.xml without specific details in spec itself, see https://github.com/Matroska-Org/matroska-specification/pull/223/files for an example, so everyone is aware of identifiers reserved for a third party tool. Should such elements be in a separate document, mp4ra style?

Jérôme

I have read your PR in Matroska (yet nobody has answered) and it is first time reading about RAWcooked. I'm sure there are not much people how know about this project.

To add new Matroska elements for this "little" project is in my eyes too much. But I can understand how important it is for you and the project.
I wait already a  long time for a PR but It has become quiet around Matroska.
When I have more time to work on Matroska Menu I'm afraid it will take a lot of time to add new elements.

Then I thought about this problem and maybe is the solution useful.
Inspired by Haali TRACKSETEX which uses the Matroska Tags!

Here my suggestion:

Add a top-level Tag with a SimpleTag with Title RAWCOOKED. Then add for all your RAWcooked elements nested-SimpleTags.
In the RAWcooked project is a RawcookedBlockGroup element(probably very often used) which is distributed of the entire file.
To collect all RawcookedBlockGroup values, you must read the entire file which takes a while, but with Matroska Tags a reader needs less milli seceonds.
You could change all RAWcooked element values without re-muxing the mkv file.
You could change the RAWcooked project structure and have also backward compatibility.

Every "private" project could add his own Matroska Tags structure. Every developer can then decide which projects are supported(Matroska reader/Splitter).



For HEVC Hdr data we should add new Matroska elements because this are stream base data.


Kind regards
Martin Below

 --------------5B9174D4CDB77CD70EF4349B-- From nobody Fri Apr 13 12:27:43 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6C212783A for ; Fri, 13 Apr 2018 12:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeBy-wbyboV0 for ; Fri, 13 Apr 2018 12:27:40 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 E7C64126C89 for ; Fri, 13 Apr 2018 12:27:39 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id h143-v6so4518973ita.4 for ; Fri, 13 Apr 2018 12:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xF7RmPX+owiPPePqUe2kDVV/FEj9FPn8DWx08xZovGs=; b=F0QsXvvF9CBUJYFHLmo+FqvXsRh6S3GXSyF0BVN5rMYcVCLaVtSi6G9lupGzciWy3E gwSvICQwSgY1OCpYKfXOwN5xgSoFGEfdZHbA/0Hv9DKbOYYLOSiR+JdNHNg+u5Azigci PAI0cRNgmggFuqo8Rng5IFKOBnvZT9rrGxcsdckicJWpSsIFQDkPm+IHykUiIb2VHC0O jCtRYN5PGlDDqMYoMdwvwh7gLhtiyuCX7R9AOIq3IX7ztvKKrycN/oYj6B/d0BeLp+hp fVkQD7r4dW3GjwFwtD+nyMsBWvyG8zGF+cjyhCTmuDpl3K9iYLJhrUZGNzsKorJ7NtT8 pSRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xF7RmPX+owiPPePqUe2kDVV/FEj9FPn8DWx08xZovGs=; b=ZKjitgc3khbWWhvnHuX6KC/Kx53Hul+joVVWwXPfqBjRdzbsjzckgV3DhaSNS85H9t t/uMvrbd4Xr6jn28txpn8rjSCvMGr3HiOFcC1qQtPYdKkTgv90gyz1PPC/4wbP2Yw5Y2 QDPMTXdgoLlWd1rzthYI+FtQ48xSK9d4gj/k2MJxh829M0IDX4w6VgGS8amIhw6gIb3I 2i6nxIGE/wm+VdUxXcBn0u1YIFWmWeCY7bObroqfx0GiJQ7amFs1IzZSqAImNvO/OCWp Y7BrjGxBM+1PFpj8eoRpeHJv2UFVHcaDvQ8Z0/QqoChyv0Yw4mX9m4lVmqcrMNxArHTO wFDg== X-Gm-Message-State: ALQs6tB91ytPnV/jODSDg9d/dPnu9C0b2zxqQ42SWKNUoBecUxWw9XNL Ljk0qsGTCSq1bCm4852Lg9gV/X5mxOUcDTIs7aag6w== X-Google-Smtp-Source: AIpwx4/wQfC3pU++LuZHQGKK26ThIJLDtlKfHu5RSYw575orXkiXcUYWDe0HkOeh2bampYYvvq1e3cBKZc1933Sz+r4= X-Received: by 2002:a24:e4c2:: with SMTP id o185-v6mr6651380ith.37.1523647658825; Fri, 13 Apr 2018 12:27:38 -0700 (PDT) MIME-Version: 1.0 References: <3318390e-0647-289d-d52b-e2c9678b24f7@gmx.ch> In-Reply-To: <3318390e-0647-289d-d52b-e2c9678b24f7@gmx.ch> From: Michael Bradshaw Date: Fri, 13 Apr 2018 19:27:27 +0000 Message-ID: To: hubblec4@gmx.ch Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000007839300569bfdd34" Archived-At: Subject: Re: [Cellar] Adding private elements to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 19:27:42 -0000 --0000000000007839300569bfdd34 Content-Type: text/plain; charset="UTF-8" I concur with Martin. For this particular case, I don't think new elements should be introduced just for RAWcooked. RAWcooked, could instead add an attachment or tag that contains its needed metadata. In general, I'm opposed to private elements in Matroska. If, for some reason, attachments and tags aren't feasible, I could concede to adding a new global master element that is comprised of two child binary elements: one acting as an identifier, and one acting as a payload. That way any arbitrary private info could be identified stored anywhere in the file. But I'd prefer to avoid that, if possible. --0000000000007839300569bfdd34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I concur with Martin. For this particular case, I don'= t think new elements should be introduced just for RAWcooked. RAWcooked, co= uld instead add an attachment or tag that contains its needed metadata.
In general, I'm opposed to private elements in Matroska= . If, for some reason, attachments and tags aren't feasible, I could co= ncede to adding a new global master element that is comprised of two child = binary elements: one acting as an identifier, and one acting as a payload. = That way any arbitrary private info could be identified stored anywhere in = the file. But I'd prefer to avoid that, if possible.
--0000000000007839300569bfdd34-- From nobody Fri Apr 13 12:56:34 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A51128896 for ; Fri, 13 Apr 2018 12:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty3w3NV58Yix for ; Fri, 13 Apr 2018 12:56:32 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F378C1289B0 for ; Fri, 13 Apr 2018 12:56:31 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:32946) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1f74o5-0007rg-02 for cellar@ietf.org; Fri, 13 Apr 2018 21:56:25 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id C96896542244 for ; Fri, 13 Apr 2018 21:56:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1523649384; bh=uv+6j6Gjmd+YBQrV+IYED30qVlieEXc6FudXuN83j3Q=; h=References:From:To:Cc:Subject:In-reply-to:Date:From; b=fazziwGZGDkNFsCE1VwXkWbNbd+XYk/aPu6TI4uaQesFRDnaDnG91uAwS3T/mWk+1 2zFMJvaP6kfkWLmv1R+vC6lutBI+nj2tMXxWvmBVqZosEImRFTs95Kgf1EVEDEtiv5 GF/kVKjYMkoOBqUtk9Sq8R6OSbN8U/ar+pUt7r/DyjG6YVRpI6UEFVnYW1Y1IuyKeo WQUTkbpBFeYNlGp8m5fwljpVM2B/Hl4X4HUzbTtodngNbL8Gc82CLHT37o7zYcHm0m I2u4drJENrpBuBdzK0JGjUIQU763VIdZUp7JtYFXMmscQ/a4DtAqUJrofeZLD69BYl ZmNSLb3KLmatJBni6M2F4R/2MOE7o+T7NpSKmMcEB8F4bGTKxed6DKk4ndDJu6+riB cVdUNg6SFMkudCq45cwOogPxxk+SxYXdHtbWuvRdeXx8YM7VYo6GJ1znMH386XcvM0 ykC56KySzYIcLC38p0B7RHwb/gnC5bYEoRxQA42Kr+Lte5b188oSmveZyrvLFiQfuY DBXaWLgq8inR5pTSijowE7LppYSchZhIfbMIypci4lXJaIK/KOXVB4P3hwaLAR4ZgC 6SpBsJkDbsc62HH5WUMB/8Ax1vyhFsVwUUQXfdv/8pjicqpkoC0TwMEXjtz1lBh9nZ DyTIWwYwr663Ddx4g1Gxg7cs= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 1CCF03554A8B for ; Fri, 13 Apr 2018 21:56:24 +0200 (CEST) References: <3318390e-0647-289d-d52b-e2c9678b24f7@gmx.ch> User-agent: mu4e 1.0; emacs 25.3.1 From: Moritz Bunkus To: Codec Encoding for LossLess Archiving and Realtime transmission Cc: In-reply-to: Date: Fri, 13 Apr 2018 21:56:24 +0200 Message-ID: <87vacu2847.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] Adding private elements to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 19:56:34 -0000 Hey, > In general, I'm opposed to private elements in Matroska. If, for some > reason, attachments and tags aren't feasible, I could concede to adding a > new global master element that is comprised of two child binary elements: > one acting as an identifier, and one acting as a payload. That way any > arbitrary private info could be identified stored anywhere in the > file. But I'd prefer to avoid that, if possible. That would be the equivalent of a tagging system with arbitrary key/value pairs, albeit without the existing targeting facilities (the \Segment\Tags\Tag\Targets element). I don't like that approach much, e.g. because it would mean duplication of data if the same private data should be applied to multiple tracks. Additionally the scope of such elements wouldn't be entirely clear: would there be a difference between that element being a direct child of a \Segement\Tracks\TrackEntry and being a child of e.g. \Segment\Tracks\TrackEntry\Audio? I'd rather see the use of the existing attachments & tags systems for this. Kind regards, mosu From nobody Sun Apr 15 05:31:12 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E576A1243F3 for ; Sun, 15 Apr 2018 05:31:10 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAmzYG5Sc0K1 for ; Sun, 15 Apr 2018 05:31:09 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 267A81200C5 for ; Sun, 15 Apr 2018 05:31:09 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id y63so2606510pgy.12 for ; Sun, 15 Apr 2018 05:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EKcMGQPbZtehmfnJnZAIFy8HUgGvll4QA/PH4TJKEUg=; b=kf5h5GrrRex01u++VeTMOCBeiHFYk7SpeuPonCyurNpqkpWNAPu/TeUdE0IEqihDnM vFHRGkVdRz+qty4WnKn3e8qN9hNca2BuG1G6W/ai4pOCbca8zzSgBHrXLvSHMSV+cAEr lUQs5N0/uG4C7oNtlgDQ4c4i5CS7nueB3cm8pfT5h3PppiVghHOOLSImbrNsyzt8DgG1 svLUjefWcJ+7k1I33b7SO8QkYnKay9aOnlMEzUFKsSBx6RTrHGRR3e6VBbFvi1l9PimW qr58uRUtjZopMylufi5hnME8oBfwuy2B8k+tP/wuGkpF6rNGjGhZO2fX0hWQbFcz/yb0 UL2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EKcMGQPbZtehmfnJnZAIFy8HUgGvll4QA/PH4TJKEUg=; b=i3r3RXqvOUimtKqcbALIUcVPHVstCh6kraftQtu3/FocmLCNXkxKfHwQHBLhIxZ3hu 8bGlo/rLn2Y9GHK4+aQKJmeg/kEQkUZl3MmhkDloUvRxKUqqVmjJLwRK3YQzLk7ZW9gY K3ctiAdBZJmLPbOJd09o0OSDZxM1Nw4J7ZqQQtkSVKGODpFRaVNiFEFBDZqnEjlhRijr +VObYSYkRzpAqPRNgw32GQ8XFR5774OYvW3yqOmCHY0Xqvt6dDhVCSs12yJNeCGsaNvf N7c5LDvnaesTwA7rSHPxCoeo2KFbjAWFGrtqzkNKhkBg47sFv158I7pT3S0FxCgzCp0r uMOA== X-Gm-Message-State: ALQs6tCDq+kenMc6OO2talJ+So+qTqNJKnglpwEheNHoukYOtjHnXDy4 exHr08gyHlgdK0AWvzar9/EQs7kN6vnUf1FLu095iQ== X-Google-Smtp-Source: AIpwx4+ipgI31mXOSzzoQr3NwYFwww5IZm8+5/zEiMcgoXHD0hwH97oQeE6TpMiIru7bAHjyddp0f//KKdXgenQj2Dg= X-Received: by 10.99.9.66 with SMTP id 63mr7773447pgj.103.1523795468581; Sun, 15 Apr 2018 05:31:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.164.196 with HTTP; Sun, 15 Apr 2018 05:31:08 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 15 Apr 2018 14:31:08 +0200 Message-ID: To: Ben Campbell Cc: Codec Encoding for LossLess Archiving and Realtime transmission , "Timothy B. Terriberry" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] CELLAR Chairs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 12:31:11 -0000 Hello, It seems there are no volunteers ? I would step in but I have hardly experience with moving things at the IETF... Is it possible to publish a request in the NETVC group as I think it's more populated, has existed for longer and has more experience ? 2018-04-09 18:02 GMT+02:00 Ben Campbell : > Hi CELLAR Participants, > > As some may have heard, Tessa stepped down as co-chair prior to IETF 101.= We are currently looking for a replacement co-chair. Suggestions are welco= me; given the current state of the CELLAR milestones, I=E2=80=99d like to f= ind someone experienced with moving work through the IETF processes. > > Tim will remain as the other co-chair. I=E2=80=99ve asked him to expedite= the working group last calls for the appropriate documents. > > Thanks! > > Ben. > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Apr 15 05:55:42 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC3E1200C5 for ; Sun, 15 Apr 2018 05:55:40 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rU9DvZ1WgAU for ; Sun, 15 Apr 2018 05:55:38 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94971200A0 for ; Sun, 15 Apr 2018 05:55:38 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id p10so2618903pgn.1 for ; Sun, 15 Apr 2018 05:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=EctuC5K/jElbTCxlxEyz+M0smoKQ33ji7dp2yPJ3C9I=; b=MySEWBQTMow2qUpVzayn1jFpB7doBirVepunQ7gfeygK65tio2xM4JYkEgf/89QBnR Ph/tWB7lY/2K2lTcfopEW2QNWIzzSVRfAd7nVYeeDGQVB+VGiMp4KcOof8GkosLFDBx3 DDkuTgkzaqUTggD1ARH5HBGyn5DGOwOn8IRCTZnJKLPL522fDYm2BNsFE/9MISbmRn5q JUphhzMgjrJ0OYfW3Qmtn7B/ZJqTxd8OrM6Tl0Enyp23tlHMUscMjp6mJgt/Zyt7vYu+ mIp2BwrAYttidL09Tve1a5ZmRI8gexCC7JNg/OuuhmXQL37CuJzBOY+hRa9QVuNp5b7Z PxSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=EctuC5K/jElbTCxlxEyz+M0smoKQ33ji7dp2yPJ3C9I=; b=EbJ3INuhs2dsoxJU9wjgOZhD9wIqLxLtKbEbd3vZr2IDRwJyDzrPFD4QV8QQ7ncfee Nv1wyqVTspy7R68cs867oeIjCAV+bp07vh71a6ehCfLeGEF6Jl1S8fIP/rWAsAp3AgSF Wd+d8WbpA8YVQCfZQcYYJnGOSAIfDBDqJBMnrt/fTTzw5Z7084ElKHAfcUt5uJ8KxgPc neKszOEgvaO9QaO3uOfmehx2IJ5s1HTdw+6oCe79I7es3D/pIkOA4S0RB0jji2pATE9h WUfBoa87ymbbObIC4ookWnjRJW0KK9Zd+Yhok206SXLo/vE5KsIUqperqOlaWbRIWQhL GFRA== X-Gm-Message-State: ALQs6tCcbYpESigfqyZ2XLe8bqdYZS2DZNyp8tRQhpdW6RDHEWH7dNfS OvNAagIze+SMw3/Nnv3L12Np4fUHIsWitJliA0A9BQ== X-Google-Smtp-Source: AIpwx49lMgsQTIUt7DqC6CLj8PyfnLRfBbLg9nGDvOJpRuYXDuVBIDrZ9fpU5AA3iGT7uL7kUVTf7psR3zsS4ZbKiT4= X-Received: by 10.101.97.208 with SMTP id j16mr10026029pgv.431.1523796937605; Sun, 15 Apr 2018 05:55:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.164.196 with HTTP; Sun, 15 Apr 2018 05:55:37 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 15 Apr 2018 14:55:37 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Adding private elements to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 12:55:41 -0000 Hi, 2018-04-13 11:35 GMT+02:00 Jerome Martinez : > I am working on a project related to Matroska and I would like to add som= e > private elements to Matroska, at different levels (TrackEntry, BlockGroup= , > Segment). > These elements add no specific features for media playback. > > As there is no indication about how to add private elements (no element i= s > reserved for hosting private sub elements), Matroska conformance checkers > currently flag new elements as "unknown". OK, that's something we need to define. And that should be at the EBML level, not Matroska. - how to add new elements that will not be assumed to be invalid IDs by past parsers/validators ? - how to define elements that are not meant to be merged in the main DocType specs (like Matroska v5) but on the side ? We already have the case of the DivX elements that are currently in the XML file we use to define all the elements. But they should not be part of the Matroska specs. It should be a separate XML file that attaches to the main specs. For example in mkvalidator you can specify that you are validating a DivX MKV file which allows these extra elements. Otherwise they are not allowed. > I would like to debate about how to add new elements to Matroska, for som= e > specific needs so more flagged "private", and for future needs for Matros= ka > (e.g. HDR metadata was added during CELLAR work, what should be done in t= he > case CELLAR already released the spec?). The HDR metadata make sense in Matroska. The DivX one are specific to their use (trick playback) and yours also seem to be related to a particular case that don't make sense elsewhere. I would not call them private though as they will probably be defined publicly (the DivX ones are or were at the time they made them). For truly private elements we could do nothing at all and let people making use of them dealing with the issues. It depends how we solve the cases of DivX and RAWCooked. If we add some info in the EBML header then they could benefit from the same feature. > Some questions: > - IMO a new element should not make a new version mandatory, as new eleme= nt > are ignored by players, but what should be the behavior of a conformance > checker? error raising if the element is not known, information only? May= be > we need a paragraph about it in specs. It depends if the element is meant to be merged in the main spec or not. From the beginning Matroska was designed to be able to play with as few elements defined as possible. The elements that need to be added are the ones essential for playback. HDR falls in that category, if you don't store the information the file won't play correctly. Chapter elements used by ordered edition also affect playback so would probably need to bump the Matroska version. The DivX one is special as it's not necessary for playback, it just adds an extra playback mode. And it's not used by anyone else and uses an older DocType version. But I would move it out the current specs. If anything, to show how it's done to add extensions to Matroska. On the other hand if EBML header additions are needed, all the existing files would be invalid... > - How to manage private elements? Difficulty is to be sure an element > identifier used by third party A is not reused by third party B due to B = not > knowing about A.On my side I suggest to just add it to ebml_matroska.xml > without specific details in spec itself, see > https://github.com/Matroska-Org/matroska-specification/pull/223/files for= an > example, so everyone is aware of identifiers reserved for a third party > tool. Should such elements be in a separate document, mp4ra style? If it's private you have no way of knowing it doesn't collide with anything else. Wether it's element IDs or a private element with a sub-ID. You just can't tell if it's not used anywhere else or if it will never be used. That's another good reason to make it public, even if you (not YOU) don't want to share what you really do with the data. > > J=C3=A9r=C3=B4me > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Apr 15 06:30:15 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BAD1200A0 for ; Sun, 15 Apr 2018 06:30:13 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvyhJph4Uaay for ; Sun, 15 Apr 2018 06:30:11 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::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 718D61200C5 for ; Sun, 15 Apr 2018 06:30:11 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id 59-v6so8555896plc.13 for ; Sun, 15 Apr 2018 06:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=AdTq3fSHt3XvOqjMpicgtbFhiwJYeXwwyLsVAyo+/9Q=; b=P3gWo50xx4fS/L+5rcQDSbd/Nk0z10YXMBuYV2pRQkm6+zj4JEJdp7zUQDFKIjvkVw N28rFCh0pQMYTHnZU490BAjx1MfJXQcL9+FXllegbfD4Cu1NFLHxbYw039brGcggGwoG YBe5qiuDE8eJgRJHrCauVWMteJb+QlDfIWm64xw9IQhGCZVYd9vykIWML6eIsTpAbxUT 6nvOMMppOW0CLa2K8NdTEt0FB/Wji0B4xPrzhAfuYLwkevfJKHyuxa2RD28mLX4DZ30n Jbyxpxj2vnTjPcpcWMDBmqnw3DCRS7Tl8samCCobeY/a+SAPupysnrl7MuhdC8eXjOWb DU6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AdTq3fSHt3XvOqjMpicgtbFhiwJYeXwwyLsVAyo+/9Q=; b=M2lgwHBejPSgRVHmx8p6ssmsxro/ICrq0ryAwNqCTziTsXNOZEwEu5OiJ9Mx9h46AY wKXJODPOdk3apEU9I1nMF+Z5OHwkERriSAfY1B6LamyLms/QVWLUcwmKUOEVp8KYqFKn 1+e4FCgcqoLaYqJhOyba97fy6Il6zmhDLzkxtpp339V9LFbwySYuaGDtmfZm464qR3Qc kVeiRHtmO7rr3iLIakT7fL0V837y+OlOEYfKk0p+9bJWkbP3DR4LPDaqMk9noTpbnpjC F5S1+/ww5JHdkVrBhwzIRcA1jF4o/28rCTui/LVx+j5zYHTsL5nqRF10dU+5gyU61wpe cyhw== X-Gm-Message-State: ALQs6tDosOqX/zfY7ZfBCUTtIwFBLOYPGcRbTVgdkU95WoXCoAPy4lay FmUfVvd++RrX+QnrPfA+d0ZLNV2qYXP0TK+POgoqjQEp X-Google-Smtp-Source: AIpwx489+556cHvJGaHFC5EqXieINFpYJZR4hPwLUZ5eDrnr8/QJUhqquhtaAz/K6J5G/0pg86nvGh7FMuHrOeCG7iQ= X-Received: by 2002:a17:902:9a44:: with SMTP id x4-v6mr12231201plv.312.1523799010663; Sun, 15 Apr 2018 06:30:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.164.196 with HTTP; Sun, 15 Apr 2018 06:30:10 -0700 (PDT) From: Steve Lhomme Date: Sun, 15 Apr 2018 15:30:10 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] EBML Extensions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 13:30:14 -0000 Following the discussion on RAWcooked elements we need a way to define how to create extensions to a DocType that are not meant to be merged in the main DocType specifications. The XML Schema we use is already quite good for external files as we can define the exact path an element can be found, independently of the main specs. We even have fields in the header to tell which DocType and which version of the DocType it applies to. What we don't have is these information when reading an EBML file. We know the DocType and the version but we don't know of any extensions that are also valid in this file. If we had a DTD/Schema embedded in every EBML file that would be where we put these data. But we don't. And there may be simpler way to do it, in the same philosophy as EBML/Matroska: only write information that's not obvious. We can take the RAWcooked elements as an example for what we need: https://github.com/Matroska-Org/matroska-specification/pull/223/files This should be a separate XML file that has the same DocType and version as the current Matroska one. https://github.com/Matroska-Org/matroska-specification/blob/master/ebml_matroska.xml We may also include a human readable name for the extension like extension="RAWcooked". The 3 added elements and that's it. That would be enough for the extension definition. In the file/stream we should tell if this extension is used, when it's used. The logical way to do that is to put this information in the EBML header. We will also need the IDs, the path where they belong and at least if it's a master element or not (to allow children elements). The path actually contains a lot of information like the maximum of occurrences or if it's a recursive element and even how the recursion works. The goal is not to interpret the values but only to tell what is valid and not valid we may not need to know the exact type of the value and the allowed ranges. But that could be added as well. The path would probably be in a binary format. Especially as the elements name are not known. So in the case of RAWcooked we would have something like that stored in the EBML header: EBML EBMLExtensions EBMLExtensions ExtensionName: RAWcooked ExtensionElement ExtensionElementPath: 0*1(\0x18538067\0x1F43B675\0xA0\0x207262) ExtensionElementHasChildren: 0 (may be the type otherwise) ExtensionElement ExtensionElementPath: 0*(\0x18538067\0x207273) ExtensionElementHasChildren: 0 ExtensionElement ExtensionElementPath: 0*1(\0x18538067\0x1654AE6B\0xAE\0x207274) ExtensionElementHasChildren: 0 We could add extra elements like a URL to know more about that extension, a human readable name for each element, etc. The URL may also replace the ExtensionName. The separators between IDs may be kept as we need a way to wrap things in this way: 1*(\Segment\Chapters\EditionEntry(1*(\ChapterAtom))) Opinions ? Given the state of EBML it may be for a subsequent version of EBML so we don't delay the current one further. -- Steve Lhomme Matroska association Chairman From nobody Sun Apr 15 06:38:01 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FF71200C5 for ; Sun, 15 Apr 2018 06:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA5rdARb0RYM for ; Sun, 15 Apr 2018 06:37:57 -0700 (PDT) Received: from 6.mo3.mail-out.ovh.net (6.mo3.mail-out.ovh.net [188.165.43.173]) (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 683151200A0 for ; Sun, 15 Apr 2018 06:37:57 -0700 (PDT) Received: from player797.ha.ovh.net (unknown [10.109.122.97]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id 3AFFD1B2514 for ; Sun, 15 Apr 2018 15:37:54 +0200 (CEST) Received: from [192.168.2.120] (p5DDB6BF5.dip0.t-ipconnect.de [93.219.107.245]) (Authenticated sender: jerome@mediaarea.net) by player797.ha.ovh.net (Postfix) with ESMTPSA id 7E8292E0096 for ; Sun, 15 Apr 2018 15:37:52 +0200 (CEST) To: cellar@ietf.org References: <3318390e-0647-289d-d52b-e2c9678b24f7@gmx.ch> From: Jerome Martinez Message-ID: <96dcc36b-13c6-ee26-8f02-a4c2c30a3f21@mediaarea.net> Date: Sun, 15 Apr 2018 15:37:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Ovh-Tracer-Id: 6174716564471222417 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrieeigdehlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Adding private elements to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 13:38:00 -0000 On 13/04/2018 21:27, Michael Bradshaw wrote: > I concur with Martin. For this particular case, I don't think new > elements should be introduced just for RAWcooked. RAWcooked, could > instead add an attachment or tag that contains its needed metadata. Current implementation of RAWcooked uses an attachment, this method has some advantages, e.g. can survive over a remux if attachment are copied, but also some drawbacks, e.g. all is in a single place (maxOccurs for "Attachments" element is 1) which may be a problem in some corner cases (redundancy, need to keep in memory or elsewhere all RAWcooked data before being able to store the file at the end of the encoding...). As Tags element has no maxOccurs, I could use it for storing data corresponding to e.g. the previous cluster (Tags is at Segment level only), with a TagName having a "magic value" specific to my project (as I do with attachments right now) and TagBinary containing the corresponding data, but it is usable only at the Segment level, so not generic way to define private content in other Matroska elements. > In general, I'm opposed to private elements in Matroska. Even if the outcome for RAWcooked is to avoid to create Matroska elements, other projects may decide that this is the only solution for them, and if we (as people working on Matroska spec) don't define a way to store private elements, people may do as DivX did (if I remember well, DivX first decided to create some new Matroska elements, then Matroska people put them in spec in order to avoid so get collision), which is maybe not the way we want it. Most modern formats have private elements (MPEG-TS has registration_format_identifier in descriptors for knowing what is used for table_id>=0x80,  AVC/HEVC uses "user_data_unregistered" in user_data followed by uuid_iso_iec_11578 for uniqueness, MP4/MOV uses "uuid" atom also followed by an UUID...), even AV1 is planning METADATA_TYPE_PRIVATE_DATA metadata type for storing private data, I guess it is not for nothing ;-), so I think that planning nothing for people wanting to store unspecified content is a good method, if we plan that Matroska is even more used that currently, so any company would be interested in storing private content as they do for years when they use a format. > (...) From nobody Sun Apr 15 06:47:05 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F30124E15 for ; Sun, 15 Apr 2018 06:47:04 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9YNf5HuBqox for ; Sun, 15 Apr 2018 06:47:03 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 013E51242F5 for ; Sun, 15 Apr 2018 06:47:03 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id a2so9326044pff.8 for ; Sun, 15 Apr 2018 06:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=52aQQkGFY/wXs6mR0mTXGSXOlha8kyhq2RKdCUUe4ag=; b=mlxy/kLkdl32fe69QQARdhxZb2e25d2HHRMvAs1ta9/A6Zq1Xon7tc0ApSWLJcya8n +GEJxi27WCs6bUb5RRRoFdfLOIJc08Yj5VB1iloc2Cu/m+V/uehGP2nEa25rbKKJowyL MhwGNBaj1lm7h3kbXJgXIYIt7AfpEZoetqNkHw772wmsBZY3wo2pq3tr6m2kgck6TTuu wZn2sbtkf9kRrZvzHTMpvH1Zf9v2b+7SYWLWOacCTxQMoeYMhGOav9hV2MbT+IJLj+7d nGSHTRMYIMRHSgyFLHrEXk2XRZOqfzAfndwGqUU/r3dqUrqEMKbBd8fpfoYb404dIta2 JfuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=52aQQkGFY/wXs6mR0mTXGSXOlha8kyhq2RKdCUUe4ag=; b=nHhsRksUn8ZMpDyTvTbHyTYkDTbiDHLLYh5i16lWkkJRKLRVfUcIFUOE7/pa5SS9iF SYwrLLAl92J4VyWO6cPGhTvIqfl0jZIirDslJPnV3yvxjj6wHFdxkeuLSTcShxzCh0tp mwvDt6o+30YrgIDRitdP2V8fz6w20zIgJDXK6ohFSlqrTH5Xbz+wwkF+n7MBWGvogkLp Iaud+peQJ7OKJC1LXB0LHU9pMKbuyAii9XO4+5HlV9rVqvdr6Spgcn8IES31xyeInNKT eRd7WQb13zFopYJg1dWkw1IZGkQIbArT68g0Cy4aRrvPKlhOB4mWOGpVRXhyl4niM6ly oj0A== X-Gm-Message-State: ALQs6tC/EtuOv5Apnb+/FshWBmbUsUsl9vVk/adPtz8QqTbF7zr7amtt OD2uy11o6VrPXphlysbi0fHkwLrtG8CkpBnwagweNA== X-Google-Smtp-Source: AIpwx49Qg1BWU17fsfVU5ukUyR074+ESJI65dkr/WDfw0+n4c2q23R/gO2ftPz3D0W589I13G2BcEuq2vTbq1Bgnch8= X-Received: by 10.99.9.66 with SMTP id 63mr7936382pgj.103.1523800022555; Sun, 15 Apr 2018 06:47:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.164.196 with HTTP; Sun, 15 Apr 2018 06:47:02 -0700 (PDT) In-Reply-To: <96dcc36b-13c6-ee26-8f02-a4c2c30a3f21@mediaarea.net> References: <3318390e-0647-289d-d52b-e2c9678b24f7@gmx.ch> <96dcc36b-13c6-ee26-8f02-a4c2c30a3f21@mediaarea.net> From: Steve Lhomme Date: Sun, 15 Apr 2018 15:47:02 +0200 Message-ID: To: Jerome Martinez Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] Adding private elements to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 13:47:05 -0000 2018-04-15 15:37 GMT+02:00 Jerome Martinez : > On 13/04/2018 21:27, Michael Bradshaw wrote: >> >> I concur with Martin. For this particular case, I don't think new elements >> should be introduced just for RAWcooked. RAWcooked, could instead add an >> attachment or tag that contains its needed metadata. > > > Current implementation of RAWcooked uses an attachment, this method has some > advantages, e.g. can survive over a remux if attachment are copied, but also > some drawbacks, e.g. all is in a single place (maxOccurs for "Attachments" > element is 1) which may be a problem in some corner cases (redundancy, need > to keep in memory or elsewhere all RAWcooked data before being able to store > the file at the end of the encoding...). > As Tags element has no maxOccurs, I could use it for storing data > corresponding to e.g. the previous cluster (Tags is at Segment level only), > with a TagName having a "magic value" specific to my project (as I do with > attachments right now) and TagBinary containing the corresponding data, but > it is usable only at the Segment level, so not generic way to define private > content in other Matroska elements. > > >> In general, I'm opposed to private elements in Matroska. > > > Even if the outcome for RAWcooked is to avoid to create Matroska elements, > other projects may decide that this is the only solution for them, and if we > (as people working on Matroska spec) don't define a way to store private > elements, people may do as DivX did (if I remember well, DivX first decided > to create some new Matroska elements, then Matroska people put them in spec > in order to avoid so get collision), which is maybe not the way we want it. > > Most modern formats have private elements (MPEG-TS has > registration_format_identifier in descriptors for knowing what is used for > table_id>=0x80, AVC/HEVC uses "user_data_unregistered" in user_data > followed by uuid_iso_iec_11578 for uniqueness, MP4/MOV uses "uuid" atom also > followed by an UUID...), even AV1 is planning METADATA_TYPE_PRIVATE_DATA > metadata type for storing private data, I guess it is not for nothing ;-), > so I think that planning nothing for people wanting to store unspecified > content is a good method, if we plan that Matroska is even more used that > currently, so any company would be interested in storing private content as > they do for years when they use a format. I think you're comparing to formats that are not easily extensible by nature (I might be wrong). EBML/Matroska allows private extensions without breaking anything. DivX did it, WebM did it. It's just the validation/remuxing of files that may cause problems. > >> (...) > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Sun Apr 15 06:49:24 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7F4126B72 for ; Sun, 15 Apr 2018 06:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5mJP0mMvMGQ for ; Sun, 15 Apr 2018 06:49:21 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918231242F5 for ; Sun, 15 Apr 2018 06:49:21 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:55954) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1f7i1n-0006Pj-2S; Sun, 15 Apr 2018 15:49:11 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 8BDA065414BB; Sun, 15 Apr 2018 15:49:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1523800151; bh=whTs8cRf5JCGRVEE1L8CgxA7P8HjweKzhNu7dVi27cI=; h=References:From:To:Cc:Subject:In-reply-to:Date:From; b=v0Quio+tcNeQ2ppZ5AKcmSAM4sch19BEVx3TXtI+hzXKAF/ff6AVH6SsDrpuoZsSn lSfuELL/XlCakqXEz/dtvB1julAcDWoV/idSl3oQGMi9gHlYC8BTv5CDv/1ZxuXu+B NxbYrnhtWDU2nnyBFqBkW/AItmYLPT4afPNgtYk+9vIy3SeEQjf9rzqWNDujUp7fD5 SSb213i90RhAtXA1wRk6MwDlxv0Vj4A5iVXsxHVI8ZlDeJETp/anhJ4gV90b6lkMzF kqRiDq8Z/dH7RndA0xktyiWpCT+2wjOMDUK4JvHFAy7muRIiChfBC+duthGlYO6xo8 VwLtO4IDUZAS1zBpNgHMq2xybg1c2JWkyrOY0clsCc8P22gAozHHCD+aPU4Nw0j5MM jaAynvihDAa7IHqDLR5U3iZtCi3W/t7COMXL7B6OgCieJRvisqJkhD+gARtdy3Fd6d RX50VDEec1+2rUY4dZI2tZBCDtgFijrxxZ422zbMAji9HnTgedEiQjXN1726jUY5xr 01Ma3GSs37zl1ZOgjSMgw1M9G/J6Ci0YzgYBCOaiemfUV5PrObG0uzv5gDupmqmuH/ MKCoDVkZb5aJRgLdRqsiOTGxuXEPSPXjmYbEHkXQKiIfq3nhfiqJ2KLRo2RGWIZJD4 yURJJDRmRMgRA+iNZMNnaUN8= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id CDEBF356D8C7; Sun, 15 Apr 2018 15:49:10 +0200 (CEST) References: <3318390e-0647-289d-d52b-e2c9678b24f7@gmx.ch> <96dcc36b-13c6-ee26-8f02-a4c2c30a3f21@mediaarea.net> User-agent: mu4e 1.0; emacs 25.3.1 From: Moritz Bunkus To: Jerome Martinez Cc: cellar@ietf.org In-reply-to: <96dcc36b-13c6-ee26-8f02-a4c2c30a3f21@mediaarea.net> Date: Sun, 15 Apr 2018 15:49:10 +0200 Message-ID: <87sh7w1sx5.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] Adding private elements to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 13:49:23 -0000 Hey, I'm not particularly against private _data_ inside Matroska, but more against private _elements_ as we already have ways of attaching arbitrary data (tags & attachments). We could simply define a schema for private tag names and be done with it. Kind regards, mosu From nobody Sun Apr 15 06:55:08 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0B9124319 for ; Sun, 15 Apr 2018 06:55:07 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hepIyi3s_dkb for ; Sun, 15 Apr 2018 06:55:05 -0700 (PDT) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB1B1242F5 for ; Sun, 15 Apr 2018 06:55:05 -0700 (PDT) Received: by mail-pl0-x22f.google.com with SMTP id t20-v6so8590079ply.9 for ; Sun, 15 Apr 2018 06:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=p+SfqfHBhhy0rHaQea4Ohpt1RRU8ZNiGKqzfeXpkwC0=; b=lKhCknyDdGEyJACBBRl0fgXKFBtoa/MhB7+2OU8JZKX1I1yRH58t85y4mcwFQtQach 0djjyv5dLl7Qt/R5AI0mbmqu7coLzQRs8DowNRinQPO7EJ2CYS4U/6yuLMQxT1781VrA JKLthQpPPWXlfPdpScwuVffRh/lOFoX6sG/Q5/UXnWtyuqRUHXDdE0YJI85cqhQOlK1S vNnCxf7zPMgCI07hqbnfNiGsyalA2HtsG7g64S/m1p9h5W/FbetUDR6ooalwo4xClSrq nfrzdjRkVUg1zKZU+BbkA7bKqqj2HYwpACSlCaLfnIKHZl3TW2Cmr0YhEye2irp0Fl/M OvUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=p+SfqfHBhhy0rHaQea4Ohpt1RRU8ZNiGKqzfeXpkwC0=; b=PG8fEL1l9gKh7jv5/7EK/Q5cxienRniw+z59yISB+k5Zy/xrZj7ZCULeAZ3NioaC+b 8+r8b/NUhMBhXIDyj5QXm2ooZibhx/zID5IgvNr0nCOmY2Pcgd+CcFJZ8NXdenYcOHhy oQ/hP+dhe2q4Imdbjy3H+m4dr7LHiH/KOasFnmWhqUAcTDyhi5JR8zVQ3lfNp+7dwju5 2q/wCJ4tzDvSygciCPB/LxZ5mmdztDwe6HBDJDkKVuf2o6gL5qpMO4Ih+mfMeN3gtYC/ O3ZfD9SnmGVEgE+TaPwe3hCk6YzfGioCbAWTKLPO01dDC3mwiwjBU0AEkiVtw9lwb3dR Nryw== X-Gm-Message-State: ALQs6tDwpBumA3P0DHs05IgZtm+5+XTohX0eVFOF0+T7SZneG5GNPcyi xDhDHFx1LT/YwtIMaBI6fSdhjni9VaOEQ7xDQg8kBg== X-Google-Smtp-Source: AIpwx49gFJVThNKd+yR4qhZyNMc9zEY04aRPXQz+mxkaV9lNTKhPAlAJLOLBuJSUQky1f1E0njNXnBNAWBn+0HXO8Lg= X-Received: by 2002:a17:902:9a44:: with SMTP id x4-v6mr12292067plv.312.1523800504454; Sun, 15 Apr 2018 06:55:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.164.196 with HTTP; Sun, 15 Apr 2018 06:55:04 -0700 (PDT) In-Reply-To: <285b49b2-0255-6cef-dc69-e2cb2b312e1a@gmx.ch> References: <285b49b2-0255-6cef-dc69-e2cb2b312e1a@gmx.ch> From: Steve Lhomme Date: Sun, 15 Apr 2018 15:55:04 +0200 Message-ID: To: hubblec4 Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] when is ChapterEndTime required X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 13:55:07 -0000 To follow up on this, the specs should probably be clearer about this. Since there are cases where the chapter end time is not needed, it can't be mandatory. But in the ordered chapters case, it cannot work if a chapter end is missing. Although the end may come from the chapter parent if it has one... 2018-03-28 18:58 GMT+02:00 hubblec4 : > Hi all > > > Am 28.03.2018 um 17:51 schrieb Dave Rice: >> >> Hi cellar, >> >> This is to follow up on a discussion on ffmpeg-devel, see: >> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227453.html. In the >> Matroska Schema, the ChapterTimeEnd element is optional, but in >> https://github.com/Matroska-Org/matroska-specification/blob/master/chapt= ers.md#editionflagordered >> it says "If an Edition of Ordered Chapters is enabled then the Matroska >> Player MUST play those Chapters in their stored order from the timecode >> marked in the ChapterTimeStart Element to the timecode marked in to >> ChapterTimeEnd Element.=E2=80=9D > > Thats right and for a "normal" ordered edition the endtime stamps are > required. What means "normal": This is the case when ChapProcessCodecID i= s > set to 0(default 0). > If this value is set to 1 then Matroska-DVD-Menu system is used and there= is > it possible to have empty endtime stamps. > >> >> So is ChapterTimeEnd required when EditionFlagOrdered=3D1? > > Yes. >> >> Is the second edition of the example below (from >> https://archive.org/download/chapters_test/chapters_test.mkv) invalid to >> write or invalid to read? > > I'm sure Mosu's Chapter Editor(Matroska Reader) can read such mkv's but a > Matroska Player will fail to build a correct virtual timeline. > LAV Splitter ignores all ordered chapters with a play-duration of 0 or le= ss. > An empty endtime stamp is like a value of 0 so you get a negativ chapter > play duration. > Chapters_test.mkv plays the first editon, but when you change to edition= 2, > playing is stoped, timeline greyed out, play-button is disabled and so on= . > There is no virtuell timeline for the second edition. > > Read and write is maybe possible and not really invalid, but for practice > using is it invalid. > >> Should we state a fallback end time (segment duration?) when there is no >> ChapterTimeEnd in an Ordered Edition? > > A fallback which used the segment duration is possible only when you have > only one chapter. Otherwise the new virtuell playtime is too large and > duplicates video content. > The Segment duration is not a "good" value because this element is not > always present AND (very)often too large. > >> >> |+ Chapters >> | + Edition entry >> | + Edition flag ordered: 1 >> | + Edition flag hidden: 0 >> | + Edition flag default: 1 >> | + Edition UID: 3475548369 >> | + Chapter atom >> | + Chapter time start: 00:00:15.000000000 >> | + Chapter time end: 00:00:20.000000000 >> | + Chapter flag hidden: 0 >> | + Chapter flag enabled: 1 >> | + Chapter UID: 12865469183194029579 >> | + Chapter display >> | + Chapter string: Random Red Ball >> | + Chapter language: eng >> | + Edition entry >> | + Edition flag ordered: 1 >> | + Edition flag hidden: 0 >> | + Edition flag default: 0 >> | + Edition UID: 12338659363134957115 >> | + Chapter atom >> | + Chapter time start: 00:00:00.000000000 >> | + Chapter flag hidden: 0 >> | + Chapter flag enabled: 1 >> | + Chapter UID: 17174098126947929771 >> | + Chapter display >> | + Chapter string: Full >> | + Chapter language: eng >> >> Dave Rice >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > > > Kind regards > Martin Below > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Apr 15 07:00:22 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880511242F5 for ; Sun, 15 Apr 2018 07:00:17 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XMT2uaC53xH for ; Sun, 15 Apr 2018 07:00:15 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::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 BE611124319 for ; Sun, 15 Apr 2018 07:00:15 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id 59-v6so8576777plc.13 for ; Sun, 15 Apr 2018 07:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bZfvf0uvWp4tvy/NwVB9VoJvLjEkEg30hKeF6VtmV5A=; b=qMZwm0nBDF9fbrp/ixOxkRjG02S2EqpRcd9IVsm2m7a2Svw88tpsAi8I8H7dpv9oPb zo74OmwKckRYKj8Y3oyaTADJCWQ6oJXRzRrxk4kjPPWheIyLPlVkEmJpQKylnFDOd8g3 DQnWB5Yn4llKZ0iHXh6vt9/89g9VJpByhmnN6YgQLxnBm1GmiG8OWxSlLIMMkzAUNEs9 zt4bp9r4zvxGLNmvN4NMVVh+9LbnBSWKDnJYK4RqmgLCY1unlpXOuZZNNpUcalfwIaf0 brqShAB7Jf+hOiek2eKeIFWum/1tdPdeYH06PcBF4G+PRRziJS7vl8Z7/z05i2eCmc9i cE/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bZfvf0uvWp4tvy/NwVB9VoJvLjEkEg30hKeF6VtmV5A=; b=kicMp7RpXarkQgkmEmniwzzxnMXhzwtcFI51WHyGQyhOKU7VdIlXkWMwK8Bkh/Ba/l vpPkBvegMSjfC9GKxySEQxaDz1kzCULH7IEdkXyWjGsnlFpauRE+sv9EAXM0rqlfUMqw LQ0TsuTG/7PSTlYIdx0l7DbU6/wsHVHQ7QHu2SCR/2K+Oi5xvkJjpmu9tofiZ/ltWXxz Hbdlx5sKKx0hwC8fa7X3u9Tzy6Rul07ft6MKc4bM0P3KxhNtPNUGUBjdLfDZRMT4tt0U /JVQ4jt2kLo8PlZunjv5CLfwF9ewW9SpVQ1w3cpzuF6iVAwnuFbjuVKHbxiH1drJa5HT Bs2Q== X-Gm-Message-State: ALQs6tBDN4sEoYYPVN2jE6KGaMNXCsF11CMnKhSt8FYBeAvRjfWMmAL9 IhecqVovq9DHVCOf8X5zEcRhPPwDXC+kliMYXb/dxg== X-Google-Smtp-Source: AIpwx4/TZULxysfhfkXNXt7G0FDeJ2uE3lR908+9z2Do1DFIRSmo19DX4FwRVhNqEbJzJWRR0HDqksfjBl/BnuHmGUU= X-Received: by 2002:a17:902:7185:: with SMTP id b5-v6mr11863601pll.221.1523800815320; Sun, 15 Apr 2018 07:00:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.164.196 with HTTP; Sun, 15 Apr 2018 07:00:14 -0700 (PDT) In-Reply-To: <87sh7w1sx5.fsf@bunkus.org> References: <3318390e-0647-289d-d52b-e2c9678b24f7@gmx.ch> <96dcc36b-13c6-ee26-8f02-a4c2c30a3f21@mediaarea.net> <87sh7w1sx5.fsf@bunkus.org> From: Steve Lhomme Date: Sun, 15 Apr 2018 16:00:14 +0200 Message-ID: To: Moritz Bunkus Cc: Jerome Martinez , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] Adding private elements to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 14:00:18 -0000 But would we define an element for each level where one can appear (that would be a lot) ? Or do we define a global element similar to Void/CRC32 that is open bar for whatever you put it in, but a bit too loose for validation. The latter may be a simpler possibility and we use an element ID with 2 or 3 bytes to avoid false positives. Like Michael suggested an ID + value may be useful too. The issue would be for readers, they will have to map and signal this element every time it's found. At least this approach is a lot simpler that defining a whole system to put in the EBML header. 2018-04-15 15:49 GMT+02:00 Moritz Bunkus : > Hey, > > I'm not particularly against private _data_ inside Matroska, but more > against private _elements_ as we already have ways of attaching arbitrary > data (tags & attachments). We could simply define a schema for private tag > names and be done with it. > > Kind regards, > mosu > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Sun Apr 15 07:24:10 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC952126C25 for ; Sun, 15 Apr 2018 07:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJxXdXiuaIiD for ; Sun, 15 Apr 2018 07:24:07 -0700 (PDT) Received: from 8.mo69.mail-out.ovh.net (8.mo69.mail-out.ovh.net [46.105.56.233]) (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 0B8991242F5 for ; Sun, 15 Apr 2018 07:24:07 -0700 (PDT) Received: from player797.ha.ovh.net (unknown [10.109.122.11]) by mo69.mail-out.ovh.net (Postfix) with ESMTP id 3552111937 for ; Sun, 15 Apr 2018 16:24:05 +0200 (CEST) Received: from [192.168.2.120] (p5DDB6BF5.dip0.t-ipconnect.de [93.219.107.245]) (Authenticated sender: jerome@mediaarea.net) by player797.ha.ovh.net (Postfix) with ESMTPSA id 95B6A2E0095 for ; Sun, 15 Apr 2018 16:24:03 +0200 (CEST) To: Codec Encoding for LossLess Archiving and Realtime transmission References: <3318390e-0647-289d-d52b-e2c9678b24f7@gmx.ch> <96dcc36b-13c6-ee26-8f02-a4c2c30a3f21@mediaarea.net> From: Jerome Martinez Message-ID: Date: Sun, 15 Apr 2018 16:24:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Ovh-Tracer-Id: 6954683725119950993 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrieeigdeikecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Adding private elements to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 14:24:09 -0000 On 15/04/2018 15:47, Steve Lhomme wrote: > 2018-04-15 15:37 GMT+02:00 Jerome Martinez : >> [...] >> Most modern formats have private elements (MPEG-TS has >> registration_format_identifier in descriptors for knowing what is used for >> table_id>=0x80, AVC/HEVC uses "user_data_unregistered" in user_data >> followed by uuid_iso_iec_11578 for uniqueness, MP4/MOV uses "uuid" atom also >> followed by an UUID...), even AV1 is planning METADATA_TYPE_PRIVATE_DATA >> metadata type for storing private data, I guess it is not for nothing ;-), >> so I think that planning nothing for people wanting to store unspecified >> content is a good method, if we plan that Matroska is even more used that >> currently, so any company would be interested in storing private content as >> they do for years when they use a format. > I think you're comparing to formats that are not easily extensible by > nature (I might be wrong). MP4/MOV has a similar method about element, there are 2^32 possibilities. But it does not prevent conflicts, as 2 entities may use the same element name (2^32 possibilities, but people may limit their choice to a subset of possibilities, e.g. easily readable in English), I guess this is the reason "uuid" atom appeared later in files. > EBML/Matroska allows private extensions > without breaking anything. DivX did it, WebM did it. It's just the > validation/remuxing of files that may cause problems. > Taking the example of DivX, issue is if 2 entities use accidentally the same element name before seeing that the other has chose the same element name. From nobody Sun Apr 15 07:33:45 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79C21242F5 for ; Sun, 15 Apr 2018 07:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPiwN1f2tJHp for ; Sun, 15 Apr 2018 07:33:41 -0700 (PDT) Received: from 20.mo6.mail-out.ovh.net (20.mo6.mail-out.ovh.net [178.32.124.17]) (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 AF8011200F1 for ; Sun, 15 Apr 2018 07:33:41 -0700 (PDT) Received: from player797.ha.ovh.net (unknown [10.109.108.57]) by mo6.mail-out.ovh.net (Postfix) with ESMTP id ED1E0153739 for ; Sun, 15 Apr 2018 16:33:39 +0200 (CEST) Received: from [192.168.2.120] (p5DDB6BF5.dip0.t-ipconnect.de [93.219.107.245]) (Authenticated sender: jerome@mediaarea.net) by player797.ha.ovh.net (Postfix) with ESMTPSA id 7BF642E00A3 for ; Sun, 15 Apr 2018 16:33:39 +0200 (CEST) To: cellar@ietf.org References: <3318390e-0647-289d-d52b-e2c9678b24f7@gmx.ch> <96dcc36b-13c6-ee26-8f02-a4c2c30a3f21@mediaarea.net> <87sh7w1sx5.fsf@bunkus.org> From: Jerome Martinez Message-ID: Date: Sun, 15 Apr 2018 16:33:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <87sh7w1sx5.fsf@bunkus.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Ovh-Tracer-Id: 7116531837518418065 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrieeigdejtdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Adding private elements to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 14:33:44 -0000 On 15/04/2018 15:49, Moritz Bunkus wrote: > Hey, > > I'm not particularly against private _data_ inside Matroska, but more > against private _elements_ as we already have ways of attaching arbitrary > data (tags & attachments). We could simply define a schema for private tag > names and be done with it. Issue I see here is that tags are at Segment level only, so does not permit to be in other elements. A workaround would to permit Tags (or Tag) elements everywhere (like Void and CRC32), but IMO Tags are very specific (in specs: "specific to Tracks/Chapters"), not broad enough. I would a dedicated Matroska element for that. While I think to RAWcooked usage because it is my use case, I try to think to all potential possibilities and potentially usage may be everywhere in Matroska elements (e.g. for MOV file, "uuid" atom can be everywhere, from doc: "UUID atoms for specific extensions may be placed in any position where a succession of atoms is permitted") From nobody Sun Apr 15 08:37:17 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C501270A3 for ; Sun, 15 Apr 2018 08:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRoalxlBjfH0 for ; Sun, 15 Apr 2018 08:37:06 -0700 (PDT) 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 2C2C1124B18 for ; Sun, 15 Apr 2018 08:37:06 -0700 (PDT) Received: from [10.0.1.86] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3FFb4ma025662 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 15 Apr 2018 10:37:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.86] From: Ben Campbell Message-Id: <255455E2-2C9C-4939-BF3A-694436AECA99@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BBF8C058-2F4B-45B5-8003-3170C26782D6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sun, 15 Apr 2018 10:37:03 -0500 In-Reply-To: Cc: Codec Encoding for LossLess Archiving and Realtime transmission , "Timothy B. Terriberry" To: Steve Lhomme References: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Cellar] CELLAR Chairs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 15:37:08 -0000 --Apple-Mail=_BBF8C058-2F4B-45B5-8003-3170C26782D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Steve, I think we=E2=80=99ve got someone lined up. Expect an announcement soon. Thanks! Ben. > On Apr 15, 2018, at 7:31 AM, Steve Lhomme = wrote: >=20 > Hello, >=20 > It seems there are no volunteers ? I would step in but I have hardly > experience with moving things at the IETF... Is it possible to publish > a request in the NETVC group as I think it's more populated, has > existed for longer and has more experience ? >=20 >=20 > 2018-04-09 18:02 GMT+02:00 Ben Campbell : >> Hi CELLAR Participants, >>=20 >> As some may have heard, Tessa stepped down as co-chair prior to IETF = 101. We are currently looking for a replacement co-chair. Suggestions = are welcome; given the current state of the CELLAR milestones, I=E2=80=99d= like to find someone experienced with moving work through the IETF = processes. >>=20 >> Tim will remain as the other co-chair. I=E2=80=99ve asked him to = expedite the working group last calls for the appropriate documents. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >>=20 >=20 >=20 >=20 > -- > Steve Lhomme > Matroska association Chairman --Apple-Mail=_BBF8C058-2F4B-45B5-8003-3170C26782D6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrTcZ8ACgkQgFZKbJXz 1A0qeQ/9GfGsWVzseUTceYW24pSdD4LL12pP2iwzn6ySq84xXaXPvoky4ArYJxKa /LYmtqamIh6bdfSfM/g0C60DtrDbOnjom5P+MjApGTnE/VB/jFiFVuWmt0jQs6PW Y1U844vysedGiM9hJjMBaQ6tCnEcxLJke/vInGg2Hl86ckQ53si92cwQq9PLFPF7 ZUUvOhhkmI5BqLbsHAoo9bD+OosvpB04hYrHnN1mNq57hhVR1iT+zsA3sDg27YtA l2VgxRygmgFEdOgb4KsII951voagnzx3nSlspMiRaxMzWrIWceeQDWZ6Vu9oe6p8 HwVWnC7Xm2J33wmAEPQ6EW4u1h9+UCoRbHfBnNqM8rGlVffvuBcKqKhADW4ShFSI ONv2ZcLloCRq0a2QBCFf+JwHirI1IufrXG/kWjUyNjkaPJb5AWbmV+5hU3GZvvM0 xnyo8Jy36wgX8c0/dYd118IQtbCmVN0NdWb0O6ifC8XGJ5OdgSBSyRURseI4g48+ UNx4vvJ8pR0c7bZuLliKQqCkHf8fozYidZGgFYi5qWjZWCm9QEcOfkalT2WhTNDi xg+0r0Z/BaDOqCEoBR5zRNUhP6fM+gtDiqvEYecmzhiqzyRdGACVyH/07Ce+Jlpz mr7sDj2EUhPcrknkHYz8upMJPs2sCJ/RznDzmHlnAiXAntk6TvI= =3WTr -----END PGP SIGNATURE----- --Apple-Mail=_BBF8C058-2F4B-45B5-8003-3170C26782D6-- From nobody Sun Apr 15 08:44:13 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55F1127867 for ; Sun, 15 Apr 2018 08:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeZxgRs8YHNE for ; Sun, 15 Apr 2018 08:44:08 -0700 (PDT) Received: from 9.mo5.mail-out.ovh.net (9.mo5.mail-out.ovh.net [178.32.96.204]) (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 02E6B1270A3 for ; Sun, 15 Apr 2018 08:44:08 -0700 (PDT) Received: from player730.ha.ovh.net (unknown [10.109.105.46]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id EA7621A07B0 for ; Sun, 15 Apr 2018 17:44:05 +0200 (CEST) Received: from [192.168.2.120] (p5DDB6BF5.dip0.t-ipconnect.de [93.219.107.245]) (Authenticated sender: jerome@mediaarea.net) by player730.ha.ovh.net (Postfix) with ESMTPSA id 9EDCC4400A3 for ; Sun, 15 Apr 2018 17:44:02 +0200 (CEST) To: cellar@ietf.org References: From: Jerome Martinez Message-ID: Date: Sun, 15 Apr 2018 17:44:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------94DC54CA789F33255933808A" Content-Language: en-GB X-Ovh-Tracer-Id: 8305482137877483665 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrieeigdekhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] EBML Extensions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 15:44:12 -0000 This is a multi-part message in MIME format. --------------94DC54CA789F33255933808A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 15/04/2018 15:30, Steve Lhomme wrote: > Following the discussion on RAWcooked elements we need a way to define > how to create extensions to a DocType that are not meant to be merged > in the main DocType specifications. > > The XML Schema we use is already quite good for external files as we > can define the exact path an element can be found, independently of > the main specs. We even have fields in the header to tell which > DocType and which version of the DocType it applies to. > > What we don't have is these information when reading an EBML file. We > know the DocType and the version but we don't know of any extensions > that are also valid in this file. > > If we had a DTD/Schema embedded in every EBML file that would be where > we put these data. But we don't. And there may be simpler way to do > it, in the same philosophy as EBML/Matroska: only write information > that's not obvious. > > We can take the RAWcooked elements as an example for what we need: > https://github.com/Matroska-Org/matroska-specification/pull/223/files > > This should be a separate XML file that has the same DocType and > version as the current Matroska one. > https://github.com/Matroska-Org/matroska-specification/blob/master/ebml_matroska.xml > We may also include a human readable name for the extension like > extension="RAWcooked". > > The 3 added elements and that's it. That would be enough for the > extension definition. > > In the file/stream we should tell if this extension is used, when it's > used. The logical way to do that is to put this information in the > EBML header. We will also need the IDs, the path where they belong and > at least if it's a master element or not (to allow children elements). > The path actually contains a lot of information like the maximum of > occurrences or if it's a recursive element and even how the recursion > works. > > The goal is not to interpret the values but only to tell what is valid > and not valid we may not need to know the exact type of the value and > the allowed ranges. But that could be added as well. > > The path would probably be in a binary format. Especially as the > elements name are not known. > > So in the case of RAWcooked we would have something like that stored > in the EBML header: > EBML > EBMLExtensions > EBMLExtensions > ExtensionName: RAWcooked > ExtensionElement > ExtensionElementPath: 0*1(\0x18538067\0x1F43B675\0xA0\0x207262) > ExtensionElementHasChildren: 0 (may be the type otherwise) > ExtensionElement > ExtensionElementPath: 0*(\0x18538067\0x207273) > ExtensionElementHasChildren: 0 > ExtensionElement > ExtensionElementPath: 0*1(\0x18538067\0x1654AE6B\0xAE\0x207274) > ExtensionElementHasChildren: 0 > > > We could add extra elements like a URL to know more about that > extension, a human readable name for each element, etc. The URL may > also replace the ExtensionName. > > The separators between IDs may be kept as we need a way to wrap things > in this way: 1*(\Segment\Chapters\EditionEntry(1*(\ChapterAtom))) > > Opinions ? While I like the idea of defining some "schema" in EBML header, I am wondering what is the actual usage: for a conformance checker, it helps to consider unknown elements as "expected", but is it useful? Shouldn't a conformance checker just discard unknown elements, expecting that it was defined later (compared to when the conformance checker was built)? Additionally, I understand you talk about third party extension, but don't we have the same issue with official new Matroska elements? when we freeze Matroska v4, how should be considered new elements if the DocVersion is still 4? in other words, does DocType of 4 mandates a precise list of elements, or is it "open"? IMO, thinking more and more about that, it should be "open" and a conformance checker should just ignore unknown element or list them in an information area. For third party extensions, I see that the proposal does not resolve the issue about collisions. even if collisions may be rare, people may want to use shorter ones so a collision would not be so rare. And it does not indicate which ID to use, i.e. if we (specification writers) don't know which element was used by third parties, how will we avoid to use an element ID not used by someone else who did not indicate us that an element is used? Worse, let imagine at EBML level: we want EBML to be used in more places, but what would happen if spec author X define element Y in the spec (nothing forbids him to do so), and EBML authors decide to add a global element with value Y (the same value) because they were not aware of author X and his spec? So I think we have a more global issue: we have reserved values nowhere (not in EBML, not in Matroska), and it may be important to consider that as an issue to resolve before flagging EBML as "final version 1". Checking e.g. 1-byte elements, I see that we have already 78 (76 Matroska + 2 global EBML) 1-byte elements defined, other 128 possibilities. Not a lot are remaining for future EBML global 1-byte element... I suggest that we first reserve (for all classes?) some EBML IDs for future global elements, before we can't use any new Global element due to Matroska using all of them. Independently (this is subject to debate, as some people don't want private elements), we could reserve a range of element IDs for private content. Even if I talked about "uuid" stuff, I don't like so much this idea because it increases the size (16 byte per UUID, in addition to EBML ID size), if I take your idea about EBMLExtension, I suggest that: - Reserve some global elements (3-byte minimum?) for private content - In EBML header, map such global element to something well defined (I don't like UUID because they are cryptic when someone faces the new value, inverted DNS or something similar to a tag name may be better) Idea is based on MXF "Primer", all 2-byte elements IDs are "user defined" and the "Primer" part in the MXF file maps them to their 16-byte "Universal Label", so the private content uses 2 bytes for element ID. Based on your proposal, it would mean something like: - We reserve 0x234500 to 0x2345FF (random values) in EBML for private content. - In EBMLHeader: EBML   EBMLExtensions       ExtensionElement         ExtensionValue: 0x234562         ExtensionMeaning: "RAWcooked/RawcookedBlockGroup"       ExtensionElement         ExtensionValue: 0x234572         ExtensionMeaning: "RAWcooked/RawcookedTrackEntry"       ExtensionElement         ExtensionValue: 0x234573         ExtensionMeaning: "RAWcooked/RawcookedSegment" Just an idea as a potential solution for the issues I see with your idea and issues in general about EBML, but I have no strong ideas about how to handle them, someone has other ideas? --------------94DC54CA789F33255933808A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 15/04/2018 15:30, Steve Lhomme wrote:
Following the discussion on RAWcooked elements we need a way to define
how to create extensions to a DocType that are not meant to be merged
in the main DocType specifications.

The XML Schema we use is already quite good for external files as we
can define the exact path an element can be found, independently of
the main specs. We even have fields in the header to tell which
DocType and which version of the DocType it applies to.

What we don't have is these information when reading an EBML file. We
know the DocType and the version but we don't know of any extensions
that are also valid in this file.

If we had a DTD/Schema embedded in every EBML file that would be where
we put these data. But we don't. And there may be simpler way to do
it, in the same philosophy as EBML/Matroska: only write information
that's not obvious.

We can take the RAWcooked elements as an example for what we need:
https://github.com/Matroska-Org/matroska-specification/pull/223/files

This should be a separate XML file that has the same DocType and
version as the current Matroska one.
https://github.com/Matroska-Org/matroska-specification/blob/master/ebml_matroska.xml
We may also include a human readable name for the extension like
extension="RAWcooked".

The 3 added elements and that's it. That would be enough for the
extension definition.

In the file/stream we should tell if this extension is used, when it's
used. The logical way to do that is to put this information in the
EBML header. We will also need the IDs, the path where they belong and
at least if it's a master element or not (to allow children elements).
The path actually contains a lot of information like the maximum of
occurrences or if it's a recursive element and even how the recursion
works.

The goal is not to interpret the values but only to tell what is valid
and not valid we may not need to know the exact type of the value and
the allowed ranges. But that could be added as well.

The path would probably be in a binary format. Especially as the
elements name are not known.

So in the case of RAWcooked we would have something like that stored
in the EBML header:
EBML
  EBMLExtensions
      EBMLExtensions
        ExtensionName: RAWcooked
        ExtensionElement
          ExtensionElementPath: 0*1(\0x18538067\0x1F43B675\0xA0\0x207262)
          ExtensionElementHasChildren: 0 (may be the type otherwise)
        ExtensionElement
          ExtensionElementPath: 0*(\0x18538067\0x207273)
          ExtensionElementHasChildren: 0
        ExtensionElement
          ExtensionElementPath: 0*1(\0x18538067\0x1654AE6B\0xAE\0x207274)
          ExtensionElementHasChildren: 0


We could add extra elements like a URL to know more about that
extension, a human readable name for each element, etc. The URL may
also replace the ExtensionName.

The separators between IDs may be kept as we need a way to wrap things
in this way: 1*(\Segment\Chapters\EditionEntry(1*(\ChapterAtom)))

Opinions ?

While I like the idea of defining some "schema" in EBML header, I am wondering what is the actual usage: for a conformance checker, it helps to consider unknown elements as "expected", but is it useful? Shouldn't a conformance checker just discard unknown elements, expecting that it was defined later (compared to when the conformance checker was built)?

Additionally, I understand you talk about third party extension, but don't we have the same issue with official new Matroska elements? when we freeze Matroska v4, how should be considered new elements if the DocVersion is still 4? in other words, does DocType of 4 mandates a precise list of elements, or is it "open"? IMO, thinking more and more about that, it should be "open" and a conformance checker should just ignore unknown element or list them in an information area.

For third party extensions, I see that the proposal does not resolve the issue about collisions. even if collisions may be rare, people may want to use shorter ones so a collision would not be so rare. And it does not indicate which ID to use, i.e. if we (specification writers) don't know which element was used by third parties, how will we avoid to use an element ID not used by someone else who did not indicate us that an element is used?

Worse, let imagine at EBML level: we want EBML to be used in more places, but what would happen if spec author X define element Y in the spec (nothing forbids him to do so), and EBML authors decide to add a global element with value Y (the same value) because they were not aware of author X and his spec?

So I think we have a more global issue: we have reserved values nowhere (not in EBML, not in Matroska), and it may be important to consider that as an issue to resolve before flagging EBML as "final version 1". Checking e.g. 1-byte elements, I see that we have already 78 (76 Matroska + 2 global EBML) 1-byte elements defined, other 128 possibilities. Not a lot are remaining for future EBML global 1-byte element...

I suggest that we first reserve (for all classes?) some EBML IDs for future global elements, before we can't use any new Global element due to Matroska using all of them.

Independently (this is subject to debate, as some people don't want private elements), we could reserve a range of element IDs for private content.
Even if I talked about "uuid" stuff, I don't like so much this idea because it increases the size (16 byte per UUID, in addition to EBML ID size), if I take your idea about EBMLExtension, I suggest that:
- Reserve some global elements (3-byte minimum?) for private content
- In EBML header, map such global element to something well defined (I don't like UUID because they are cryptic when someone faces the new value, inverted DNS or something similar to a tag name may be better)
Idea is based on MXF "Primer", all 2-byte elements IDs are "user defined" and the "Primer" part in the MXF file maps them to their 16-byte "Universal Label", so the private content uses 2 bytes for element ID.
Based on your proposal, it would mean something like:
- We reserve 0x234500 to 0x2345FF (random values) in EBML for private content.
- In EBMLHeader:
EBML
  EBMLExtensions
      ExtensionElement
        ExtensionValue: 0x234562
        ExtensionMeaning: "RAWcooked/RawcookedBlockGroup"
      ExtensionElement
        ExtensionValue: 0x234572
        ExtensionMeaning: "RAWcooked/RawcookedTrackEntry"
      ExtensionElement
        ExtensionValue: 0x234573
        ExtensionMeaning: "RAWcooked/RawcookedSegment"

Just an idea as a potential solution for the issues I see with your idea and issues in general about EBML, but I have no strong ideas about how to handle them, someone has other ideas?
--------------94DC54CA789F33255933808A-- From nobody Sun Apr 15 23:58:17 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46F2127136 for ; Sun, 15 Apr 2018 23:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZFrOdX-j-PY for ; Sun, 15 Apr 2018 23:58:12 -0700 (PDT) Received: from mx01.mail.netstorage.at (mx01.mail.netstorage.at [IPv6:2a02:2410:b000:101:3000::c]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DF1126BFD for ; Sun, 15 Apr 2018 23:58:11 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx01.mail.netstorage.at (Postfix) with ESMTPS id 9AE96A1E61 for ; Mon, 16 Apr 2018 08:58:07 +0200 (CEST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 2C9FA81F55 for ; Mon, 16 Apr 2018 08:58:07 +0200 (CEST) Received: from [127.0.0.1] (HSI-KBW-46-237-252-214.hsi.kabel-badenwuerttemberg.de [46.237.252.214]) by mailix with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128) ; Mon, 16 Apr 2018 08:58:07 +0200 To: cellar@ietf.org References: <3318390e-0647-289d-d52b-e2c9678b24f7@gmx.ch> <96dcc36b-13c6-ee26-8f02-a4c2c30a3f21@mediaarea.net> From: Tobias Rapp Organization: NOA GmbH Message-ID: Date: Mon, 16 Apr 2018 08:58:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20180416065807.11131.21738@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com Archived-At: Subject: Re: [Cellar] Adding private elements to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 06:58:15 -0000 On 15.04.2018 16:24, Jerome Martinez wrote: > On 15/04/2018 15:47, Steve Lhomme wrote: >> 2018-04-15 15:37 GMT+02:00 Jerome Martinez : >>> [...] >>> Most modern formats have private elements (MPEG-TS has >>> registration_format_identifier in descriptors for knowing what is >>> used for >>> table_id>=0x80,  AVC/HEVC uses "user_data_unregistered" in user_data >>> followed by uuid_iso_iec_11578 for uniqueness, MP4/MOV uses "uuid" >>> atom also >>> followed by an UUID...), even AV1 is planning METADATA_TYPE_PRIVATE_DATA >>> metadata type for storing private data, I guess it is not for nothing >>> ;-), >>> so I think that planning nothing for people wanting to store unspecified >>> content is a good method, if we plan that Matroska is even more used >>> that >>> currently, so any company would be interested in storing private >>> content as >>> they do for years when they use a format. >> I think you're comparing to formats that are not easily extensible by >> nature (I might be wrong). > > MP4/MOV has a similar method about element, there are 2^32 possibilities. > But it does not prevent conflicts, as 2 entities may use the same > element name (2^32 possibilities, but people may limit their choice to a > subset of possibilities, e.g. easily readable in English), I guess this > is the reason "uuid" atom appeared later in files. > > >>   EBML/Matroska allows private extensions >> without breaking anything. DivX did it, WebM did it. It's just the >> validation/remuxing of files that may cause problems. >> > > Taking the example of DivX, issue is if 2 entities use accidentally the > same element name before seeing that the other has chose the same > element name. > Some months ago when working with AVI/RIFF I had the need to store some "sparse" file data. Basically it was an index file with all the metadata chunks except for the actual media ("data" chunk), plus some custom chunks. There I did choose a "unique" 2-char ASCII prefix for the RIFF identifiers in the hope that it would not collide with any chunks in the input AVI file. When Matroska gets more popular I assume something similar to the AVI indexing above will be implemented for Matroska and I would be in a similar situation to pick some "unique" element identifiers. In my scenario there is no problem regarding validation on output side, as the private elements are ignored when copying elements from the index file into the output file. Regards, Tobias From nobody Thu Apr 19 02:14:47 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DC3124C27 for ; Thu, 19 Apr 2018 02:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5JINCngC8Qs for ; Thu, 19 Apr 2018 02:14:45 -0700 (PDT) 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 561BB126BF7 for ; Thu, 19 Apr 2018 02:14:45 -0700 (PDT) Received: from [10.0.2.161] (ip-57-232-239-173.texas.us.northamericancoax.com [173.239.232.57]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3J9EgUF009400 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 19 Apr 2018 04:14:44 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-57-232-239-173.texas.us.northamericancoax.com [173.239.232.57] claimed to be [10.0.2.161] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (15E216) In-Reply-To: Date: Thu, 19 Apr 2018 11:14:42 +0200 Cc: "Timothy B. Terriberry" , mcr+ietf@sandelman.ca Content-Transfer-Encoding: quoted-printable Message-Id: <0480DA4A-A003-45A8-95DD-32C30647E37D@nostrum.com> References: To: Codec Encoding for LossLess Archiving and Realtime transmission Archived-At: Subject: Re: [Cellar] CELLAR Chairs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 09:14:47 -0000 Hi CELLAR Participants, Please welcome Michael Richardson as the new co-chair for CELLAR. He will jo= in Tim, who will continue in the role. Thanks! Ben.d > On Apr 9, 2018, at 6:02 PM, Ben Campbell wrote: >=20 > Hi CELLAR Participants, >=20 > As some may have heard, Tessa stepped down as co-chair prior to IETF 101. W= e are currently looking for a replacement co-chair. Suggestions are welcome;= given the current state of the CELLAR milestones, I=E2=80=99d like to find s= omeone experienced with moving work through the IETF processes. >=20 > Tim will remain as the other co-chair. I=E2=80=99ve asked him to expedite t= he working group last calls for the appropriate documents. >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Thu Apr 19 02:26:45 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6AA12711B for ; Thu, 19 Apr 2018 02:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA2yHLdxrU9d for ; Thu, 19 Apr 2018 02:26:42 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015BC124C27 for ; Thu, 19 Apr 2018 02:26:42 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:39258) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1f95pp-0002JO-33; Thu, 19 Apr 2018 11:26:34 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id C2C276540225; Thu, 19 Apr 2018 11:26:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1524129993; bh=DjnXme3cOxWy3v/pKt6Lh7W8BUU+HPEXOh66VgroHJU=; h=References:From:To:Cc:Subject:In-reply-to:Date:From; b=1L2uj4N/aBEi2lOaIhrbmkpGo60OvGxKeZMRn+kiJ6bcjP084oPOfZwUvqkx9EXSr XDQGFYU3+k+RNsN48nwWKy1MMp8FpU6hw3skPcdiAA39t6kE57YLpS4lGRMHP7Ortg fgzAYZBL6Kioq7Q9H8P9bNEAwGYBApVFGABDGeT3FeSo01IYTHUcou4ScYMssnAzbj P+4GsktmfFhRSB6TKL15egvMeqsNRjyZ3daDKBpx007/ReP7ONO2TJf7f5+pTrQzer byYnw6wDg2FZNqg/Ych2L6DHKXZ01Uxcvo7bFNRsaSwLDccyo9MEIBH2Ae10WsgnSc VJ0PnXk6t87MskOHfwL+cC342vc2FUIDmAyBGqxCv4RlhgoV0UDS5Fuosrehiby29/ PvRwXPKlBstKspY+36cFvIxLOGctieUYsstzIV5mUrlgrk/rWeS1oYmcdQV8bmaoSj YmNyEIOo3DclsBVFKn1wtrupNwlRlT9H6TtVlaZ+0KMhcirCnzchuwBX/NKvTq2sxL KKpN6T36u/hDMbr8dQWoCgzHFmrg11aeLNncs3m+tr2Jcspy+QuH9g64wii0/CCI+E 007bxaVRB0qN8LcP/5b2OUBBgI0yEzK/6etrZXPm1A8OX92IZZrh5RxxDJrrKAS8AA YkkHp5UrmY4OMMT0XMpreXh8= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 2D3DA35D22E9; Thu, 19 Apr 2018 11:26:33 +0200 (CEST) References: <0480DA4A-A003-45A8-95DD-32C30647E37D@nostrum.com> User-agent: mu4e 1.0; emacs 25.3.1 From: Moritz Bunkus To: Ben Campbell Cc: Codec Encoding for LossLess Archiving and Realtime transmission , "Timothy B. Terriberry" , mcr+ietf@sandelman.ca In-reply-to: <0480DA4A-A003-45A8-95DD-32C30647E37D@nostrum.com> Date: Thu, 19 Apr 2018 11:26:33 +0200 Message-ID: <87tvs7czsm.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] CELLAR Chairs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 09:26:43 -0000 Hey, great news, thanks for volunteering! Kind regards, mosu From nobody Thu Apr 19 07:55:17 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33831126DFF for ; Thu, 19 Apr 2018 07:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G44aotccFFmR for ; Thu, 19 Apr 2018 07:55:14 -0700 (PDT) Received: from server172-2.web-hosting.com (server172-2.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB38124F57 for ; Thu, 19 Apr 2018 07:55:14 -0700 (PDT) Received: from [146.96.19.240] (port=50219 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1f9Axn-002fmA-3u; Thu, 19 Apr 2018 10:55:08 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dave Rice In-Reply-To: <0480DA4A-A003-45A8-95DD-32C30647E37D@nostrum.com> Date: Thu, 19 Apr 2018 10:55:05 -0400 Cc: Codec Encoding for LossLess Archiving and Realtime transmission , "Timothy B. Terriberry" , Ben Campbell Content-Transfer-Encoding: quoted-printable Message-Id: <78F7A1CF-2E53-4D2D-BACF-0451C851A63F@dericed.com> References: <0480DA4A-A003-45A8-95DD-32C30647E37D@nostrum.com> To: mcr+ietf@sandelman.ca X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-2.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] CELLAR Chairs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 14:55:16 -0000 Welcome Michael! Looking forward to collaborating on cellar goals. Dave Rice > On Apr 19, 2018, at 5:14 AM, Ben Campbell wrote: >=20 > Hi CELLAR Participants, >=20 > Please welcome Michael Richardson as the new co-chair for CELLAR. He = will join Tim, who will continue in the role. >=20 > Thanks! >=20 > Ben.d >=20 >> On Apr 9, 2018, at 6:02 PM, Ben Campbell wrote: >>=20 >> Hi CELLAR Participants, >>=20 >> As some may have heard, Tessa stepped down as co-chair prior to IETF = 101. We are currently looking for a replacement co-chair. Suggestions = are welcome; given the current state of the CELLAR milestones, I=E2=80=99d= like to find someone experienced with moving work through the IETF = processes. >>=20 >> Tim will remain as the other co-chair. I=E2=80=99ve asked him to = expedite the working group last calls for the appropriate documents. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Fri Apr 20 11:37:53 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB5D127863 for ; Fri, 20 Apr 2018 11:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCW9A8rLn_dM for ; Fri, 20 Apr 2018 11:37:49 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E7F1200F1 for ; Fri, 20 Apr 2018 11:37:49 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:55030) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1f9auR-0000ZM-12 for cellar@ietf.org; Fri, 20 Apr 2018 20:37:23 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 0435C6540225; Fri, 20 Apr 2018 20:37:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1524249443; bh=Kw8OGv8SgxQYcA4UcGbUGTuW9ltvubBmlRTNYm5cjjQ=; h=From:To:Cc:Subject:Date:From; b=WTgMGlxowceuwJkGN1ecdL0hVmKGFW/+DNV2WLNWtMKzNRvWZEEAvgqwbA2dbxeHT E7Fab91jOwrDN84MwPNf0JTQi46dyAwdYKoxIYFj+gJhB/UcbzwuTDeKLstBEAg2Df 24LuD1mFAhH6uKXDB0OjM1SiO11jYHJU5jPTqVFeOKUuS57EbxlL8wn7i6aksNWcmT LaXZZfiSdREs0w9vgZnE45XZqMh5gxo5/fd1UzPBxVV3mdw0MRGL2u2Emo3uloSjml TwElVnzS7GXub82cmHAdKgNYga3hIWgCoZ/2NP1mBhLZSo0r1ihvAKW+M6jd6DrpBG S6/nBBUjdeK6R700efcVB7IB/GF4EKEZ5309+TuJGNzIcYWqujv/QyL/XD/3rC4jaz Uh3SzVZZ/BettHcZ6ZgTrLOdNy8DNxmwzIZciTOH2qbECklqPPMr/xsUTyOLPKAiQB FAl4hC53y8XHoosci0s7BPptGhO1o74yZS3KCU9uN24ALdoymv10DwXVMUSKj3hRsI JcZTH0f5X7sTdEhhn6sJJ32OAQmG24aGiGgRYmMESErdBZwswuOt48e39eu5xUGabT Q0p6jbb9dRfE9Ik2V6sT0GusUXQKk2QKXwsbNSAQ9SufIrEi3kIDI+7whK9QlJBgvs +lpZxHp960e4CiuKi0ZRmAAg= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 51C59360B44D; Fri, 20 Apr 2018 20:37:22 +0200 (CEST) User-agent: mu4e 1.0; emacs 25.3.1 From: Moritz Bunkus To: matroska-devel Cc: CELLAR list Date: Fri, 20 Apr 2018 20:37:22 +0200 Message-ID: <87o9idd8rh.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Cellar] libEBML v1.3.6, libMatroska v1.4.9 released X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 18:37:51 -0000 Hey, I've released new versions of libEBML (v1.3.6) and libMatroska (v1.4.9). Download links for the impatient: https://dl.matroska.org/downloads/libebml/libebml-1.3.6.tar.xz https://dl.matroska.org/downloads/libmatroska/libmatroska-1.4.9.tar.xz Both libraries are API and ABI compatible with their respective previous releases, libEBML v1.3.5 and libMatroska v1.4.8. libEBML's update contains a couple of minor fixes improving handling of broken or invalid date. Code of Conducts have been added to both projects. The build system of both libraries have been switched from autoconf/automake to cmake. Here's libEBML's ChangeLog since the previous release (v1.3.5): ---------------------------------------------------------------------- 2018-04-20 Moritz Bunkus * Released v1.3.6. 2018-04-19 Moritz Bunkus * Converted the build system from autoconf/automake to cmake. Patches by Github user "evpobr" with fixes by myself. 2018-04-18 Moritz Bunkus * Fixed undefined behavior when reading signed integers with negative values from files (though compilers implemented this the way we wanted them to already). * Fixed a small memory leak when reading an element runs into an I/O exception (e.g. due to having reached the end of the file). 2018-02-15 Steve Lhomme * Fixed the EbmlMaster::GetDataStart() function returning wrong values for elements with an infinite/unknown size. 2018-01-23 Steve Lhomme * Fixed finding the next element ID when garbage data is encountered during the scan for the ID. 2017-11-27 Steve Lhomme * Fixed several potential situations where reading child element data could exceed the parent element's size. 2017-11-18 Steve Lhomme * Added a code of conduct to the project. ---------------------------------------------------------------------- Here's libMatroska's ChangeLog since the previous release (v1.4.8): ---------------------------------------------------------------------- 2018-04-20 Moritz Bunkus * Released v1.4.9. 2018-04-19 Moritz Bunkus * Converted the build system from autoconf/automake to cmake. Patches by Github user "evpobr" with fixes by myself. 2017-11-18 Steve Lhomme * Added a code of conduct to the project. ---------------------------------------------------------------------- Have fun. Kind regards, mosu From nobody Sun Apr 22 07:58:36 2018 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 595A8120454; Sun, 22 Apr 2018 07:58:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152440911434.4574.16133704523443475692@ietfa.amsl.com> Date: Sun, 22 Apr 2018 07:58:34 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-02.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 14:58:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 0, 1, and 3 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-02.txt Pages : 41 Date : 2018-04-22 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-02 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 22 08:19:20 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F028124319 for ; Sun, 22 Apr 2018 08:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-YLAx9gQPc7 for ; Sun, 22 Apr 2018 08:19:17 -0700 (PDT) Received: from server172-2.web-hosting.com (server172-2.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE2C1242F7 for ; Sun, 22 Apr 2018 08:19:17 -0700 (PDT) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:40282 helo=[10.0.1.2]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1fAGll-002zp3-6K for cellar@ietf.org; Sun, 22 Apr 2018 11:19:17 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <1A850C70-3B17-4B3B-BF3B-882EC08CC2A9@dericed.com> Date: Sun, 22 Apr 2018 11:19:10 -0400 To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-2.6 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] updated ffv1 documents: draft-ietf-cellar-ffv1-02 and draft-ietf-cellar-ffv1-v4-00 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 15:19:19 -0000 Hi cellar, I uploaded a new draft of draft-ietf-cellar-ffv1 to the document tracker = at https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/. I also = submitted a draft of a new document called draft-ietf-cellar-ffv1-v4 for = approval from the chairs (once approved it should be listed in = https://datatracker.ietf.org/wg/cellar/documents/ as =E2=80=9CFFV1 = Version 4=E2=80=9D). This is the first version of the FFV1 drafts where = the documentation for FFV1 versions 0, 1, and 3 and the documentation = for FFV1 version 4 (under progress) are documented in separate drafts in = alignment of the charter=E2=80=99s milestones. Since the last version, the updates for the FFV1 documents include: - using one markdown file to =E2=80=98make=E2=80=99 separate FFV1 v0-1-3 = and FFV1 v4 drafts = https://github.com/FFmpeg/FFV1/commit/f16f9e1b1daafa9208db94496a84b9a1ecd9= 068e - more explicate notes about temporary variables in the pseudo-code = https://github.com/FFmpeg/FFV1/commit/18375b0a3ea13ffe4f28d8dff0bf5d2455b8= ec3c - optimized ceiling function = https://github.com/FFmpeg/FFV1/commit/4428eadae643aa791d9d8af73262237c38e6= 11a6 - limiting a JPEG2000-RCT exception to non-alpha frames = https://github.com/FFmpeg/FFV1/commit/4d370166448b1a33c6485165d6cd0b96c2d0= 8ea2 - initial draft of IANA considerations = https://github.com/FFmpeg/FFV1/commit/4b664e7878368996588fe97e53edb96d8113= 78db - correction to chroma subsampling references = https://github.com/FFmpeg/FFV1/commit/4ead3896beb3ddc9c47c85c663998682afcd= b49f - local definition of Container = https://github.com/FFmpeg/FFV1/commit/e7d3abbed785ce8fc03555f87c2b9a5d4259= deee - other updates for grammar, inter-sectional linking, backtick quoting Notes to chairs: The milestone section refers to FFV1 documents like this: > Jul 2017 Submit specification for FFV1 video codec version 4 to = IESG (Standards Track) [=E2=80=A6] >Apr 2017 Submit informational specification for FFV1 video codec = versions 0, 1 and 3 to IESG for publication > draft-niedermayer-cellar-ffv1 The reference to draft-niedermayer-cellar-ffv1 SHOULD be updated to = draft-ietf-cellar-ffv1since this is now a working group document. Also = obviously the dates should be updated. Best Regards, Dave Rice= From nobody Sun Apr 22 13:54:35 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B717126D85 for ; Sun, 22 Apr 2018 13:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbRF815R2Cf4 for ; Sun, 22 Apr 2018 13:54:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8AD61200F1 for ; Sun, 22 Apr 2018 13:54:31 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C18EB20091 for ; Sun, 22 Apr 2018 17:05:08 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id DEA922696; Sun, 22 Apr 2018 16:54:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DC1012694 for ; Sun, 22 Apr 2018 16:54:12 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org In-Reply-To: <5ADA6AFA.80307@mozilla.com> References: <22287.1524261740@obiwan.sandelman.ca> <5ADA6AFA.80307@mozilla.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] planning for Virtual Interim Meetings for the rest of 2018 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 20:54:35 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tim and I would like to schedule a series of virtual interim meetings. We'd like to schedule the meetings until the end of November, reserving that we might cancel one or two based upon progress and availability of people. We recognize that few of the participants in this WG are able to make it to in-person IETF meetings, and we think that virtual interim meetings would provide a useful time anchor to which to do the work. We'd like to schedule the meetings monthly, either the 4th week of the month, or the last week. If some other cadence would work better based upon some other common events we are ignorant of, please reply here. We will make the dates crystal clear once we've picked a day of the week. To that end, here is a doodle poll: https://doodle.com/poll/ux5bwnb7426p6cx8 It's a Yes/No/If-Need-Be. There are three times for each day of the week: 7am-PDT/10am-EDT/16:00-CET 10am-PDT/13:00-EDT/19:00-CET 13:00-PDT/16:00-EDT/22:00-CET =20=09 When answering please answer Yes if you would be available 75% of the time without problem. Please answer If-Need-Be if you would be available at least 50% of the time (maybe having to move another meeting), and No, if= you'd be=20 available less than 50% of the time (or never: you have recurring obligatio= ns) We will use either appear.in or webex. While Webex allows dial-in over PSTN for audio, if you would be unable to be near a computer at the time (you'd be driving, waiting at your four year old's ballet lesson, etc.) please answer at most If-Need-Be, as we would like the group to be able engage using video and in particular, screen sharing. If you haven't used appear.in or webex before and you think that your desktop OS, firewalls and/or Internet connectivity may prevent you from fully participating, please contact the chairs and we'll arrange to do a trial run with you. The goal of the meetings is not as formal as typical in-person meetings. Slides desireable from design teams, but in many cases the chairs will drive an agenda based upon a dozen or so recurring slides about current state of issues and documents. In all cases of meetings, minutes get posted back to the mailing list, and all decisions need to be ratified on the mailing list. https://www.ietf.org/iesg/statement/interim-meetings.html explains the guid= elines around Virtual Interim meetings. I've pasted some of the text at the bottom of the email. The short of it is that we can schedule a series of virtual interim meetings, but that we should have a few weeks advance no= tice=20 and permission of the area director. > Extended sequences of virtual interim meetings should be consider= ed when > numerous specific issues need to be debated. Where working group = chairs > wish to schedule a sequence of more than four virtual interims, t= he > chairs must explicitly set out the reasoning for that in a mail t= o the > list and check that there is rough consensus for that plan. Such > extended sequences also require AD approval. > > For virtual interim meetings of IETF working groups: > The meetings are scheduled by the working group chairs, who > should discuss their plans with the responsible AD(s). > > The meetings must be scheduled (timing) with fair access for all > working group participants. > > The meetings must be announced and the draft agenda published at > least one week (ideally two) before the call or session. > > Announcement text must be posted to the relevant working group > mailing list(s). > > Recurring meetings (used only if much debate is expected), may be > scheduled together, with a single announcement. A separate draft > agenda, serving as a meeting reminder, should be posted before > each recurrence. > > Minutes, including a list of attendees, must be sent to the > working group mailing list within 10 days of the event (and at > least 48 hours before subsequent meeting), and may optionally be > uploaded to the Interim Proceedings Tool > or sent > to =E2=80=8Bproceedings@ietf.org. > > Announcement text must be sent to iesg-secretary@ietf.org for > archiving purposes. If requested, the IESG secretariat will > perform an IETF-wide announcement. The secretariat will ensure > that the interim meeting is properly configured in the > datatracker. Michael and Tim =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWtz2dICLcPvd0N1lAQI32ggArNaoxsCsTSNSBjvSECYzUfHcTRwUz5bj u4mwIDATGoIYXviSSHa3/wASaYJS0NdMgplunQSQ0rK3zo+lLXD29ahEtVE3AJFi b+Y/bE+MkyNttD9hCiueMQ5GGPmpTAoJi96Cdnk8L1K5jymGYcn0JuHxdzHmyXuP 7rcycw3hl9PXVNWqD16wQ7/du+N3Aj+/+1kmx92Eu7JxyiVBs4Oxih5qfF1pDv7n OK/b0nqriDO0dH3ObDR3grYjN69UMv+7+09KCrWxiapD0oSY1Wnsa8cYRYzVh4Yj ghzYNWd3oHG8KSrrx/Z4IgrXSTNSu0WgbUW22KlyqFxZ29RbOtzZ3w== =hS7L -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Apr 22 16:46:18 2018 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAA71200FC; Sun, 22 Apr 2018 16:46:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152444077202.5384.7639161408629139467@ietfa.amsl.com> Date: Sun, 22 Apr 2018 16:46:12 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-v4-00.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 23:46:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 4 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-v4-00.txt Pages : 42 Date : 2018-04-22 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1-v4/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-v4-00 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-v4-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 26 00:20:26 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D4412704A for ; Thu, 26 Apr 2018 00:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6Ym69d98toe for ; Thu, 26 Apr 2018 00:20:23 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACFCF1204DA for ; Thu, 26 Apr 2018 00:20:21 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w3Q7KJCV029003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 26 Apr 2018 09:20:19 +0200 Received: from Castor.local (21.89.188.80.static-unalloc.cah.cz [80.188.89.21]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w3Q7KIev041666 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 26 Apr 2018 09:20:19 +0200 Date: Thu, 26 Apr 2018 09:20:19 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: [Cellar] "raw" data from scanner X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 07:20:25 -0000 Hello, the majority of the current film scanners are Bayer-based, and there are around many proprietary "raw" formats. There is also GoPro's CineForm RAW, which some scanners do use, and very recently Apple has launched ProRes RAW, which is designed for capturing and post-production. I'm still dreaming of having the possibility to store in a open way the "raw" video data info Matroska/FFV1, instead of personal hacks. Sorry for boring you with this since three years! Best regards, Reto From nobody Thu Apr 26 00:26:52 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD80A127058 for ; Thu, 26 Apr 2018 00:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3w9trGY1N5P for ; Thu, 26 Apr 2018 00:26:48 -0700 (PDT) Received: from 5.mo177.mail-out.ovh.net (5.mo177.mail-out.ovh.net [46.105.39.154]) (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 3DFEA1204DA for ; Thu, 26 Apr 2018 00:26:48 -0700 (PDT) Received: from player157.ha.ovh.net (unknown [10.109.120.50]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 50B91AF4B9 for ; Thu, 26 Apr 2018 09:26:45 +0200 (CEST) Received: from [192.168.2.120] (p5DDB40F7.dip0.t-ipconnect.de [93.219.64.247]) (Authenticated sender: jerome@mediaarea.net) by player157.ha.ovh.net (Postfix) with ESMTPSA id AB0C150009E for ; Thu, 26 Apr 2018 09:26:43 +0200 (CEST) To: cellar@ietf.org References: From: Jerome Martinez Message-ID: <169045a9-6108-1fca-ddb0-cf4078888470@mediaarea.net> Date: Thu, 26 Apr 2018 09:26:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Ovh-Tracer-Id: 9165951144809926801 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 50 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrledvgdduudefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenucgoteefjeefqddtgeculdehtddm Archived-At: Subject: Re: [Cellar] "raw" data from scanner X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 07:26:51 -0000 On 26/04/2018 09:20, Reto Kromer wrote: > Hello, > > the majority of the current film scanners are Bayer-based, and > there are around many proprietary "raw" formats. There is also > GoPro's CineForm RAW, which some scanners do use, and very > recently Apple has launched ProRes RAW, which is designed for > capturing and post-production. > > I'm still dreaming of having the possibility to store in a open > way the "raw" video data info Matroska/FFV1, instead of personal > hacks. Sorry for boring you with this since three years! I suggested a patch: https://www.ietf.org/mail-archive/web/cellar/current/msg01398.html https://github.com/FFmpeg/FFV1/pull/100 Beside time (e.g. with CineForm RAW, issue is to have a usable decoder for such stream, it takes time to adapt the CineForm RAW decoder source code to something usable for FFV1 encoder input), I am currently blocked by the lack of samples from different sources for demonstrating the feasibility and performance of the proposed patch. From nobody Thu Apr 26 02:57:54 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C331200F1 for ; Thu, 26 Apr 2018 02:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ-2GUW2lFc1 for ; Thu, 26 Apr 2018 02:57:52 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FD812D87E for ; Thu, 26 Apr 2018 02:57:51 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w3Q9vnJX009150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 26 Apr 2018 11:57:49 +0200 Received: from Castor.local (123.226.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch [178.197.226.123]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w3Q9vm7G048365 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 26 Apr 2018 11:57:49 +0200 Date: Thu, 26 Apr 2018 11:57:48 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] "raw" data from scanner X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 09:57:54 -0000 Jerome Martinez wrote: >e.g. with CineForm RAW, issue is to have a usable >decoder for such stream, it takes time to adapt the CineForm >RAW decoder source code to something usable for FFV1 encoder >input), I personally gave up this approach soon after the code has been released and in my company we do actually "intercept" the sensor's data before they are encoded in something I don't like. I would like to encode directly into correct, standard, etc. =46FV1 version N (possibly N =3D 4). That's my point. Sorry for not haven been clear! Best regards, Reto From nobody Thu Apr 26 03:01:00 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B9C1200F1 for ; Thu, 26 Apr 2018 03:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XaiJ_qH7b-t for ; Thu, 26 Apr 2018 03:00:50 -0700 (PDT) Received: from 5.mo68.mail-out.ovh.net (5.mo68.mail-out.ovh.net [46.105.62.179]) (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 3C19112708C for ; Thu, 26 Apr 2018 03:00:50 -0700 (PDT) Received: from player730.ha.ovh.net (unknown [10.109.105.14]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 4C829D2410 for ; Thu, 26 Apr 2018 12:00:47 +0200 (CEST) Received: from [192.168.2.120] (p5DDB40F7.dip0.t-ipconnect.de [93.219.64.247]) (Authenticated sender: jerome@mediaarea.net) by player730.ha.ovh.net (Postfix) with ESMTPSA id ADCA14400CD for ; Thu, 26 Apr 2018 12:00:43 +0200 (CEST) To: cellar@ietf.org References: From: Jerome Martinez Message-ID: Date: Thu, 26 Apr 2018 12:00:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6FA383FB9318841FA17C7F41" Content-Language: en-GB X-Ovh-Tracer-Id: 11767342878914777233 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrleefgddvgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] "raw" data from scanner X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 10:00:58 -0000 This is a multi-part message in MIME format. --------------6FA383FB9318841FA17C7F41 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 26/04/2018 11:57, Reto Kromer wrote: > Jerome Martinez wrote: > >> e.g. with CineForm RAW, issue is to have a usable >> decoder for such stream, it takes time to adapt the CineForm >> RAW decoder source code to something usable for FFV1 encoder >> input), > I personally gave up this approach soon after the code has been > released This is something I don't like too, after having looked at the code. >   and in my company we do actually "intercept" the > sensor's data before they are encoded in something I don't like. Whatever is the format, it may be great to have some samples (and description of the storage "format") so we can unblock https://www.ietf.org/mail-archive/web/cellar/current/msg01401.html by providing proof it is OK. Currently, it is a bit chicken and egg issue (I submitted a proposal in theory, but I have nothing for proving it is fine in practice, and looks like spec is expected before testing). > I would like to encode directly into correct, standard, etc. > FFV1 version N (possibly N = 4). That's my point. Sorry for not > haven been clear! IMO using a new colorspace_type is enough and does not mandate a new version, we could stay on v3 (lot of other formats don't upgrade their version when they add new "profiles") if we don't add complexity (e.g. my patch proposal add no complexity to the decoder, it use the same algorithm; if better compression with a different algorithm is found later, it could be in v4) --------------6FA383FB9318841FA17C7F41 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 26/04/2018 11:57, Reto Kromer wrote:
Jerome Martinez wrote:

e.g. with CineForm RAW, issue is to have a usable
decoder for such stream, it takes time to adapt the CineForm
RAW decoder source code to something usable for FFV1 encoder
input),
I personally gave up this approach soon after the code has been
released

This is something I don't like too, after having looked at the code.

  and in my company we do actually "intercept" the
sensor's data before they are encoded in something I don't like.

Whatever is the format, it may be great to have some samples (and description of the storage "format") so we can unblock
https://www.ietf.org/mail-archive/web/cellar/current/msg01401.html
by providing proof it is OK.
Currently, it is a bit chicken and egg issue (I submitted a proposal in theory, but I have nothing for proving it is fine in practice, and looks like spec is expected before testing).

I would like to encode directly into correct, standard, etc.
FFV1 version N (possibly N = 4). That's my point. Sorry for not
haven been clear!

IMO using a new colorspace_type is enough and does not mandate a new version, we could stay on v3 (lot of other formats don't upgrade their version when they add new "profiles") if we don't add complexity (e.g. my patch proposal add no complexity to the decoder, it use the same algorithm; if better compression with a different algorithm is found later, it could be in v4)
--------------6FA383FB9318841FA17C7F41--