[Cellar] Adding private elements to Matroska

Jerome Martinez <jerome@mediaarea.net> Fri, 13 April 2018 09:35 UTC

Return-Path: <jerome@mediaarea.net>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9AAC01242EA for <cellar@ietfa.amsl.com>; 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-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id v504IVLbeVRr for <cellar@ietfa.amsl.com>; Fri, 13 Apr 2018 02:35:51 -0700 (PDT)
Received: from 16.mo6.mail-out.ovh.net (16.mo6.mail-out.ovh.net []) (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 <cellar@ietf.org>; Fri, 13 Apr 2018 02:35:50 -0700 (PDT)
Received: from player755.ha.ovh.net (unknown []) by mo6.mail-out.ovh.net (Postfix) with ESMTP id B64781526BB for <cellar@ietf.org>; Fri, 13 Apr 2018 11:35:45 +0200 (CEST)
Received: from [] (p3EE2D9AA.dip0.t-ipconnect.de []) (Authenticated sender: jerome@mediaarea.net) by player755.ha.ovh.net (Postfix) with ESMTPSA id B92292600B9 for <cellar@ietf.org>; Fri, 13 Apr 2018 11:35:43 +0200 (CEST)
From: Jerome Martinez <jerome@mediaarea.net>
To: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
Message-ID: <e9160711-ca2c-b690-f720-e7e3da42b1f5@mediaarea.net>
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-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedriedvgddukecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/okW2fiIWnv9RzvI5pXGXXxclNlA>
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 <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 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 
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?