Re: [Cellar] Adding private elements to Matroska

Tobias Rapp <t.rapp@noa-archive.com> Fri, 13 April 2018 11:56 UTC

Return-Path: <t.rapp@noa-archive.com>
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 <cellar@ietfa.amsl.com>; 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 <cellar@ietfa.amsl.com>; 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 <cellar@ietf.org>; 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 <cellar@ietf.org>; 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 <cellar@ietf.org>; 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: <e9160711-ca2c-b690-f720-e7e3da42b1f5@mediaarea.net>
From: Tobias Rapp <t.rapp@noa-archive.com>
Organization: NOA GmbH
Message-ID: <bce6141f-cb3a-2c66-c9ff-4763156bada7@noa-archive.com>
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: <e9160711-ca2c-b690-f720-e7e3da42b1f5@mediaarea.net>
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: <https://mailarchive.ietf.org/arch/msg/cellar/SZ1BVYBThw4lqOuRbx6MtfxxHd8>
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 <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=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