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

Dave Rice <dave@dericed.com> Sat, 03 November 2018 23:43 UTC

Return-Path: <dave@dericed.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 3A3F8128766 for <cellar@ietfa.amsl.com>; Sat, 3 Nov 2018 16:43:32 -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, 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 AHLEv0gn1YBT for <cellar@ietfa.amsl.com>; Sat, 3 Nov 2018 16:43:31 -0700 (PDT)
Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 5AD53127598 for <cellar@ietf.org>; Sat, 3 Nov 2018 16:43:31 -0700 (PDT)
Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:40327 helo=[10.0.1.17]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <dave@dericed.com>) id 1gJ5Zf-000aXq-3J; Sat, 03 Nov 2018 19:43:28 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Dave Rice <dave@dericed.com>
In-Reply-To: <62624df3-77e8-3234-8496-30354570abee@noa-archive.com>
Date: Sat, 3 Nov 2018 19:43:25 -0400
Cc: cellar@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com>
References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com>
To: Tobias Rapp <t.rapp@noa-archive.com>
X-Mailer: Apple Mail (2.3445.100.39)
X-OutGoing-Spam-Status: No, score=-2.9
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: <https://mailarchive.ietf.org/arch/msg/cellar/CL6nTj22DloOLtw-P5fnyfzjL3k>
Subject: Re: [Cellar] Matroska Elements to support frame side data
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 03 Nov 2018 23:43:32 -0000


> On Nov 2, 2018, at 5:31 AM, Tobias Rapp <t.rapp@noa-archive.com>; wrote:
> 
> Hi Dave,
> 
> On 01.11.2018 15:03, Dave Rice wrote:
>> [...]
>> Here are a few use cases where I think this structure could be helpful:
>> === timecode
>> We’ve made many starts and stops at defining how to store timecode in Matroska but haven’t found consensus or resolution on those attempts. With the Metadata Element I think a timecode value could be stored such as
>> Cluster/
>> Timestamp=01:00:00.000
>> BlockGroup/
>> Block/
>> ...
>> Metadata/
>> MetadataName=“timecode"
>> MetadataString="01:23:45;12”
> 
> 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 4.4.2.2.1 "Time code pack (TC)”.

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.

Dave