Re: [Cellar] Matroska Elements to support frame side data

Tobias Rapp <> Mon, 05 November 2018 09:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C15112EB11 for <>; Mon, 5 Nov 2018 01:07:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hb_p3oUieSwL for <>; Mon, 5 Nov 2018 01:07:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09FE2128CFD for <>; Mon, 5 Nov 2018 01:07:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id 8A495A03B0 for <>; Mon, 5 Nov 2018 10:07:12 +0100 (CET)
Received: from mailix ( []) by (Postfix) with ESMTPA id 01D278176E for <>; Mon, 5 Nov 2018 10:07:11 +0100 (CET)
Received: from [] ( []) by mailix with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128) ; Mon, 5 Nov 2018 10:07:12 +0100
References: <> <> <>
From: Tobias Rapp <>
Organization: NOA GmbH
Message-ID: <>
Date: Mon, 5 Nov 2018 10:07:11 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
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: <>
Archived-At: <>
Subject: Re: [Cellar] Matroska Elements to support frame side data
X-Mailman-Version: 2.1.29
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, 05 Nov 2018 09:07:20 -0000

On 04.11.2018 00:43, Dave Rice wrote:
>> On Nov 2, 2018, at 5:31 AM, Tobias Rapp <> wrote:
>> [...]
>> while I think that frame side data can be useful for the DPX scenario mentioned later, I see problems with storing timecode information that way. Shall timecode be attached to the video or audio track? Shall there be some sub-classification for VITC/LTC/other timecode sources?
>> Also I would prefer the timecode value to be stored as a number instead of a string representation, for the same reason that the Cluster Timestamp element uses a numerical representation: It makes processing a lot easier.
> If the structure is sufficient then perhaps is better discussed in how to define the MetadataName values. For instance, we could define:
> MetadataName=“timecode.s314m”
> where MetadataBinary is set to a binary value as defined by SMPTE ST 314M-2005 Sec "Time code pack (TC)”.

I should clarify: Storing the timecode value as a _single_ number makes 
processing a lot easier. For example when you export a sub-range of your 
archived video file and have to shift timecode offset in the output 
file. Or when you change the video frame-rate for some reason.

Both, the "01:23:45;12" timecode string and its binary representation 
are using some display-oriented format with mixed timebases 
(hours/minutes/seconds use a fixed timebase, framecount uses another 
timebase depending on the media). In our ingest system we use a separate 
XML file to store VITC/LTC values and first tried to store the SMPTE TC 
string but then switched to storing a microseconds number together with 
some hint for presentation "these values shall be rendered at 29.97 fps 
with drop-frame counting".

> In other thoughts on this suggestion, I think it could make it difficult to easily understand if a file has a particular type of side data. For instance if only a few Clusters somewhere in the Segment contain a certain type of side data, it would require parsing every Cluster to know what types of side data are available. This uncertainly wouldn’t be the same issue if the side data was itself a Track.

I would agree here.

Best regards,